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1  In  t Toilet  ion. 

1.1  ;.,'hy  Teach  Children  Computer  Progr  imming  ? 

1.1.1  Programming  is  in  Important  Concept  to  Know. 

Computers  .ire  becoming  moie  and  mora  necessary  inl 
prominent  in  our  society-  our  I) ills  and  checks  ire 
produced  fay  computers.  The  smalLest  companies  use  data 
processinq  to  keep  their  books. 

Everyone  should  Know  how  to  deal  vita  computers,  to 
realize  that  people,  not  computers,  run  the  world.  As  T. 
Hay  Nanney  (17)  points  out,  most  major  policies  ami 
decisions  regarding  computers  will  be  made  by  non- 
computer  scientists. 

The  need  for  teaching  children  the  concepts  of  comput- 
er programming  in  elementary  school  was  recognized  by 
David  Mousoud  and  Mike  Neill  (16):  "One  mission  of  the 
elementary  school  is  to  provide  students  with  basic 
skills  of  information  processing  and  problem  solving." 
Decreased  costs  of  technology  make  it  more  and  more 
feasible  to  introduce  computer  scisace  in  elementary 
schools. 


1.  1..'    Programming    reaches    Problem    Sol.vi.nl    Techniques. 

In    writing    programs,       childien       must       demonstrate      the 

ibility      to      analyz e      problems      and    plan    solutions.       They 

must    h'.»t    proposed    solutions,    study    the    results      and,       if 

necessary,      revise      the      solutions.         The;      above    are    very 

necessary    general    problem    solvinj    techniques    that    can       be 

introduce!      to      children      in    a    simple,    interesting    way    by 

filching      thorn      computer      programming.         This      point       was 

*mp]i*""ied      bv    Dean    frown    and   tfo harmed    A.       fti-Ghannaai    (b)  : 

'in    writing    their    own    programs,       trie      children      learn       to 

organize      their      tninking      into      an    aljorithmic    form.       If 

they    are    young,     t    teacher    work;>    with    their..       Designing    and 

writing    a    new    program    is    one   o;     the    most       useful      of      ill 

peiagogical     lev  ice  u    because    it    stimulates    the    children    to 

think      of      all      possibilities    that    mignt.    occur    when    other 

ch.il  1  r en    e  x  e r c i :-> e    t  he    p ro g r a m .  " 

Papert  (22)  Lis  made  extensive  use  of  computers  to 
teich  children  problein-solviag  techniques.  His  LO'50 
system  is  used  by  adults  as  well  as  children  for  an  easy 
iVi\i  enjoyable  introduction  to  writing  programs  for  solv- 
in  ]    problems. 

1.1.  <    Programming    ')ff  ;rs    Stimulating    Open- End e J       Activities 
f  )l     Chi  J  d  ron. 


l  Introduction. 

1.1  ;.ihy  Teach  Children  Computer  Proyr  imraing  ? 

1.1.1  Programming  is  in  Important  Concept  to  Know- 
Computers  .ire  becoming  mote   and   mora   necessary   anl 
prominent   in   our   society-    C)uc   bills   and  checks  a  re 
produced  by  computers.   rha  smallest  companies   use   data 
processing  to  keep  their  books. 

Everyone  should  know  how  to  deal  vita  computers,  to 
realize  that  people,  not  computers,  run  the  world.  As  T. 
Hay  Natality  (17)  paints  out,  most  major  policies  and 
decisions  regarding  computers  will  be  wade  by  non- 
computer  scientists. 

The  need  for  teaching  children  the  concepts  of  comput- 
er programming  in  elementary  school  was  recognized  by 
David  Mousoud  and  Mike  Neill  (16) :  "One  mission  of  the 
elementary  school  is  to  provide  students  with  basic 
skills  of  information  processing  and  problem  solving." 
Decreased  costs  of  technology  make  it  mOre  and  more 
feasible  to  introduce  computer  science  in  elementary 
schools. 


1.  1.;'    Programming    Teaches    Problem    Soivinl    Techniques. 

In  writ  in  j  pragranis,  children  must  demonstrate  the 
i  i  i  1  i  t  y  to  analyze  problems  and  plan  solutions.  They 
iflust  test  proposed  solutions,  study  tha  results  and,  if 
n  ooessary,  revise  the  solutions.  The  above  are  very 
necessary  general  problem  solving  techniques  that  can  be 
introduce]  to  children  in  d  simple,  interesting  way  by 
teaching  them  computer  programming.  This  point  was 
amplified  by  Dean  frown  and  ft  oh  am  mod  A.  El-Ghannaa  (6): 
''in  writing  their  own  programs,  the  children  learn  to 
organize  their  thinking  into  an  aljorithmic  form.  If 
they  arc  young,  a  teacher  woLk:.  with  them.  Designing  an  i 
■rrit.inq  a  new  program  is  one  o '  the  most  useful  of  ail 
pedagogical  devices  because  it  stimulates  the  children  to 
think  of  a  LI  possibilities  that  might  occur  when  other 
children    exercise    the    program." 

Papert  (22)  1.  is  made  extensive  use  of  computers  t^ 
teach  children  broblem-so'lvi  ig  techniques.  His  I.O'JO 
system  is  used  by  adults  as  well  as  children  for  an  c^asy 
and  enjoyable  introduction  to  writing  programs  for  solv- 
ing   problems. 

1.1.  <    Programming    iffars    Stimulating    Open-£n.ieJ       Activities 
r  >l    ChiJdren. 


processes".  P.  J.  Barker  (2)  also  stated  that  wo 
should  think  carefully  about  the  first  prog  rammi  ng 
language  taught  to  children.  "There  is  a  strong 
indication  here  that  readability  and  accuracy  are 
connected  probably  because  most  of  us  tend  to  verbalize 
our  ideas  when  trying  to  solve  problems," 

1.3.1.2  Programming  in  "Natural  English". 

Programming  concepts  were  introduced  in  "natural 
English"  by  Killer  and  Becker  (  1r>)  .  Tne  students 
taught  to  program  in  "English;"  ased  virtually  n  :> 
tranter  of  control.  Sinse  "natural"  languages  are 
basically  linear,'  programs  written  in  "English"  used 
mostly  linear  sequencing,  as  one  would  ir  "telling  1 
story".  Programs  written  in  English  also  were  not  well 
olanned,  the  narratives  were  insufficient.  in  "natural 
linguage"  conversations  mucn  knowledge  is  taken  for 
granted  and  every  step  does  not  have  to  Pe  carefully 
detailed.  This  tendency  seamed  to  carry  over  to 
programming  when  "English"  was  used,  but  in  programming 
nothing  may  be  assumed. 

1.3.1.3  Languages   Developed   for   General    Information 
Processing. 

Southern  Illinois  University  at  Carbondale  did  1 
study  to  investigate  several  existing  general  purpose 


languages  for  tlu-ir  suitability  for  pelajogical  usvi 
(?7)»  They  use  i  tho  following  ccit'?rii  tor  eating  the 
Ian  qua  jes  : 

3.   \va  ilab  ility  of  subset  t.")c  beginners 

b.   Support   oi   upyar   lev->L   coucjos   ('.J-     data 
st  rue  tares) 

: .   Suitability   for  teachinj  about  programming  stylo 
(r^dldbl^  com,  control  structures) 

1.   Textbook  availability 

o.   Impact  of  .'.  lepartment  nin iconouter 

f.   Erficiency  md  turnaround 

j.   Language  isoi  in  "real"  world 

h  ,  S  e  r  v  i  C !  i 
"he  study  committee  concluded  that  FOPTPAN  has 
control  structure  tin Its  which  ire  some wa at  remedied  by 
"STPUCTUUED  FORTRAN",  but  th  it  would  merely  postpone 
the  issue,  LI.it'  is  too  complicated  for  beginning 
students  and  BAS7C  is  too  s  i»i  •  1  i  ;>t  ic  a  Language.  COBOL 
doesn't  have  a  good  simple  subset  and  it  is  expensive. 
Therefore  they  decided  that  PORT3AN,  LISP,  BASIC  and 
COBOL  were  definitely  unsuitable.  There  was  little 
lemand  for  ALGOL  W,  EIJI.ER,  SnOlOL  or  PASCAL  outside  the 
department-  If  this  were  not  a  factor,  they  concluded 
that  PASCAL  woull  be  the  choici  for  a  language  to  use 


in  the  introductory  courses.  At  that  point  the  lan- 
guages left  were  PL/1  anil  Assembler.  PL/1  was  chosen 
as  a  primacy  high  level  language  and  Assembler  will 
still  be  taught  to  give  the  students  an  understanding 
of  computer  structures. 
I.3.1.4    Languages    Specifically   Developed    for   Teaching. 

Several  languages  have  bean  specifically  developed 
for  teaching.  Soifle  are  variations  of  existing 
languages: 

a.  rFTHA.N"  =  Structure!  Fortran  (Fortran  with  IF_- 
THF.N_ELScl  Structure)  developed  at  General  Research 
corporation    (S) ,    Santa    Bdrbara,    California. 

b.  NSFTPAN  =  Nicely  Structured  Fortran  (Fortran  with 
inore»  control  structures)  levelopei  by  Temple 
University    (B) . 

c.  LINTIS  =  Language  for  IN  struct  ion  a  1  'JSe  (similar 
to  Algol  63)  developed  at  Bowling  Green  State 
University     (31). 

d.  PBASTC  (Basic  with  block  structures)  designed  for 
a    Brazilian    aini -comput eL     (?S)  . 

"Artificial  Languages"  have  been  developed  specifi- 
cally   for    teaching.       Included    in    this    group    are: 

a.  SIHPL-X  a  structured  Language  developed  at  the 
University    or    Maryland     (4). 


b.       HASY    -    Easy    Assembler      .jYstem      developed       it      the 
University      of    Iowa     (they    also   developed    FeachEa'*Yv 
a   cat    system   for    teachiny    -SASY    (?fi))» 
1.  }.Kr>   Using   a    "  Sequence    of    Languages". 

An    ipproach    thdT    has    not    l-een    ex  t>»  nsivel  y    triei      was 
proposed      by      Leigard       (1^).  lis      idea      is      to      teach 

progr  a.umin  j  ifn  a  sequence  ox  ten  iiirii-  la  n  judges,  each 
designed  to  toach  a  particular  computer  science  con* 
copt.  This  w.i/  each  la  ng  u-i  g>.'  would  he  simple  and  e  At'.y 
to  lwarn  and  the  progra  mmi. ng  concepts  would  bo 
i so  la  tod. 

A  sequence  of  six  subset  s  of  i>L/1  (called  SP/1 
through  SP/6)  were  developed  at  the  University  or 
Toronto  (9,1'^).  2ach  subset  wis  desi  jned  to  teach  a 
specific  concept  of  PL/1.  The  system  of  languages  is 
being  marketed  and  has  been  use!  heavily  at  the 
University  of  Toronto  since  I974. 
1.  x..'.i    Teaching    Programming    via   CM. 

Several      Universities      have       l^veloped      CAI    systems    to 

toach    compute*,    science.       Among    them    are    the    following: 

a.       PLATO    is   an   extensive   CM    project    developed    at       the 

University      or    Illinois   at    "rleiu     (1).       .'art    of    c>LATO 

is    a    lar'jo    subsystem    for      teaching      compiter      science 

(19). 


h .  Computer-Tutor,  a  CAI  system  for  teaching  cornputec 
programming,  was  developed  at  the  University  of  South 
Carolina  (13).  It  contains  a  hint  system,  subtasks 
for  expanding  on  a  topic  and  an  interactive  graphic 
debugging  i  id  *itn  a  trac->  option.  Tt  was  founi 
that:  "A  common  difficulty  among  beginning  students 
in  an  inadequate  or  inaccurate  u nderstandin j  of 
program  execution.  In  most  systems,  variaoie  assign- 
ment, logical  iecisions  arri  program  branching  aro  all 
invisible  to  the  user,  and  there  is  no  way  for  the 
student  to  see  the  flow  of  execution  of  her  program." 
1.i.}  Programming  Systems  Used  to  reach  Children. 
1.3.3.1  LOGO. 

The  LOGO  system  was  developed  at  MIT.  It  is  the 
most.  extensive  project  aimed  at.  teaching  computer 
programming  to  elementary  school  aged  children.  Tn 
developing  LOGO  Seymour  Pupert  (22)  had  "a  grander 
vision  of  an  educational  system  in  which  technology  is 
used  not  in  the  form  of  machines  for  processing 
children  but  as  something  the  child  himself  will  learn 
to  manipulate,  to  extend,  to  apply  to  projects,  thereby 
gaining  a  greater  and  more  articulate  mastery  of  the 
world,  a  s«nse  of  the  power  of  applied  knowledge  and  a 
sel f -confidently  realistic  image  of  himself  as  an 
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intellectual   agent," 

The  goal  of  LOGO  is  to  "amplify  the  correct  ways  of 
thinking"   by    teaching    the  children    to     (20): 

a.  Look    for    a    cecuusive   model. 

b.  Break    a    problem   into   sub  problems. 

c.  Look    tor   simple   and   extreme   rases. 
i.       DiscoveL    and    investigate    bugs." 

LOno  is  used  mainly  by  firth  graders  to  make 
interesting  things  happen,  including  drawing  pictures, 
making  music,  and  moving  mechanical  "turtles".  T'n^ 
children  Learn  by  causing  things  to  happen  (?J).  I'hey 
are  encouraged  t  ■>  experiment,  not  to  view  errors  as 
personal  failures.  Progr  a ■i.mi  n  q  "bugs"  are  not  their 
fault;    "the    computer    goofed"     (2  1). 

Randy  Stern  (29),  commenting  on  ficst  grade  LO'»3 
experiments  conducted  by  Cynthia  Solomon,  posited  that 
first  grade  children  "seemed  to  have  gat»s  in  their 
number  lines",  that  they  had  i i£t iculties  using  numbers 
greater  than  10.  The  children  also  2X pec ted  the 
command  "i>^"  to  move  the  turtle  to  the  right  (instead 
of  just  rotating  it).  For  teaching  LOJO  to  first 
graders,  he  recommended  simplifying  it  to  a  level 
easily    understood    by    young   children. 

Pa^ia    Perl  man    developed    TOiiTIS     (2  4)      (ToHLer's    Own 
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Recursive  Turtle  I  n  terpreti.  ve  System)  it  MIT-  With 
TORTIS,  buttons  on  one  box  represent  entire  tur^l^ 
commands  while  buttoiis  on  inotb.or  box  'ire  editing 
commands,  a  chill  starts  with  few  buttons  and  more  -i  c-; 
added    .is    he    gains    pxpprience, 

1.3.3.2    SMALLTALK, 

SMALLTALK  (11)  was  developed  at  the  iZP  }<  Palo  Alto 
Research  Center  and  is  used  in  conjunction  with  "DYNA- 
300K"  to  create  picture  books-  The  Language  is  similar 
to  LOGO-  nne  difference  is  that  the  commands  are 
symbols  instead  of  words  and  ara  accessed  via  i 
keyboard  (e.g.  pressing  a  particular  ke/  would  produce 
a  command  symbol).  As  with  LQ10,  "turtles"  and  music 
boxes  can  also  be  connected  to  the  system,  SMALLTALK 
is  primarily  used  by  junior  high  and  high  school 
students. 

1.3-3,3  SOLO. 

The  S0LOW0RKS  Computer  Labs  (28,7)  are  located  at 
the  University  of  Pittsburg*  Their  goals  are  similar 
to  those  or  the  LOGO  project  in  that  they  want  to  teach 
children  how  to  make  the  computer  do  interesting 
things.  Junior  high  and  high  school  students  use  BASIC 
to  simulate  lunar  landings,  write  cjames  -i  nd  teaching 
programs  and  work  with  graphic  displays. 
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1.1, 3.4   Other   Projects  Designed   to   Teach  Prog r dm min-j 
Concept s. 

A  course  called  "Inf.  or  mat ion"  wi.;  tau.jht  to  12  to  14 
year  olds  in  British  high  schools  (14)-  The  children 
studied  information  as  an  ossential  part  of  organize! 
human  activity.  They  learned  about  the  information 
needs  ot  society,  as  well  as  the  collection,  anilysis, 
storage  and  retrieval  of  informat ion, 
1 . '4  J  it  y  Another  Progr  amminq.  System? 

1.4.1  Special  Languages  for  Youny  Children  are  deeded. 

In  order  to  study  how  children  learn  programming 
concepts,  a  linguige  is  needed  that  children  can  issimi- 
late  easily  and  in  which  pr  ogr.  a  muling  concepts  are  clearly 
distinguished,  rhe  Language  should  be  specially  designel 
to  offer  projrinminj  to  children  it  tha  earliest  possible 
age.  This  means  that  the  language  should  not  have 
reading,  writing,  number  or  keyboard  skills  -is  prerequi- 
sites. The  representation  of  the  programming  concepts 
should  be  as  siinpl*  as  possible: 

a.  The  number  or  commands  should  be  limited, 

b.  The   commands   should   be   symbolic,  their  function 
easily  recognised-,  an  i 

c.  The    language    should    hive    few     syntactical 
const  ra  in  t  s. 
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It  should  be  possible  to  do  interesting  things  (inter- 
esting and  relevant  to  crhildren,  such  as  animation)  with 
a  minimum  exposure  to  the  language. 

A  sequence  of  mini -languages  seems  to  be  an  appropri- 
ate strategy  for  teaching  children  programming.  The 
first,  language  in  such  a  series  should  bo  chosen  ror  its 
pedagogical  suitability.  Each  langua  je  could  have  a 
restricted  environment  to  make  the  learning  of  program- 
ming as  easy  and  naturally  progressive  as  possible. 
1.4.?  PAL  is  a  Unique  Computer  Language, 

1  .4-2.1  PAL  is  Specially  Designed  for  ifounger  Audiences. 
All  commands  in  PAL  are  symbolic  pictures  which,  to 
be  invoked,  need  only  be  touched.  Reading,  writing, 
number  or  keyboard  sIciiLs  are  not  needed  to  program  in 
PAL.  (Error  messages  are  presently  written  on  the 
screen,  but  they  could  be  read  by  a  teacher  or 
transformed  into  Audio  Responses,  available  on  PLATO.) 
The  commands  of  PAL  have  few  syntactical  constraints; 
practically  all  combinations  of  commands  produce  some 
perceivable  results  which  can  be  "debugged".  PAL 
offers  a  very  restrictive  environment  which  makes  it 
ideal  as  the  tirst  in  a  sequence  of  mini -languages, 
with  perhaps  LOGO  as  the  second. 
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1*4.2.2    PAL    is    a    Progr amming   System. 

PAL  simulates  a  computer  on  the  screen,  displaying 
t he  memory,  workspace,  available  programming  and  edit- 
in  j  commands,  current  program,  program  pointer  an  1 
failure  flag  to  jive  a  total  picture  of  what  id 
happening  in  -1  computer-  The  program  execution  is 
indicated  with  a  hand  (program  pointer)  pointing  to  tne 
command    that    is    currently    being      executed.  (Barr      an  1 

joarl        (.3)       indicated      that       the      sequence      of       program 
•xecution    i  ;    difficult    for   students    to    visualize. J 

1.4.2.3    PAL   has    in    Immediate    Execution    Moie. 

It  is  easy  tor  the  children  to  gain  tar.  i  liar  it  y  with 
commands  by  usinj  them  in  in  'im.nedia  t'"»  exectuion' 
molt1.  They  can  go  back  to  "immediately  executing" 
commands  while  writing  a  pro  jam  to  remind  themselves  of 
how    to   caus°    something    to  happen. 

1.4. 2. a    PAL    rises   the    PLAT  a   Systvu. 

?AI.  is  implemented  on  PLATO  permitting  PAL  to 
incorporate  soiuj  of  the  uni-,ua  PLA^O  features,  includ- 
ing ing  the  "touch  panel"  aiu  special  characters.  As  i 
future  consideration,  PAL  cou  Id  make  us**  ol  thj*  PLATO 
audio  system.  Finally,  sir.ee  extensive  elementary 
reading  m^!  math  programs  i.-ave  been  implemented  on 
PLATO,    PAL    will    be    available    in    several    elementary 


is 


schools. 
1.U.2.5  Interesting  Things  are  Possible  with  PAL. 

With  PAL  it  is  possible  to  draw  animated  cartoons, 
draw  mazes  and  escape  from  them,  write  messages,  etc. 
(See  Appendix  :j  for  examples  of  PAL  programs.)  Later 
it  may  be  possible  ror  the  children  to  get  printouts  of 
the  displays  which  tney  have  created,  which  they  cd\\ 
take  home  is  cartoon  books. 
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}  PAL  \  n  .1  its  P  rogrammin  \    Concepts. 
..!.  1  System  Description. 
/•.  1 .  1  Overview. 

Tii  this  a  nd  ill  subsequent  sections,  ?*VL  commands  and 
program  name?  will  ho  enclosed  in  single  quotes  (')•  )ne 
square  in  the  '[lay  irea'  (see  section  2.1.2)  is  always 
the  'active  squire1  (this  is  the  current  aidress).  The 
1  active  square1  cav  be  moved  simply  by  touching  the 
lesired  new  location.  Touching  \  picture  in  the  'store' 
(road  only  memory)  causes  the  picture  to  appear  in  the 
'  finger  box'  (register  used  to  keep  trie:  of  tno  last 
picture  touched).  The  language  commands  the  i  operate  on 
thf->  'active  square'  and,  i:  applicable,  ilso  on  the 
contents  of  the  'finger  box'.  For  example,  the  command 
•join'  super imposes  the  content  oi  the  'finger  box'  on 
t.  hit  in  the  'active  square',  while  'move'  moves  the 
'active  square'  ilorrj  with  its  content!  one  position  in 
th^  direction  or  the  'move1  arrow. 


17 


2.1.2    System    Components   and    Screen    Layout 
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!.  1,1    Immediate    Sxeoution    'lode. 

Commands  aro  executed  is  they  "ii~<>  t  >uched.  For 
jxample,  the  following  sequence  of  J  touches  results  in 
placing  the  witch  on  the  screen  (the  picture  was  createi 
i- y    Linda    in    session    5,    see    Appendix    C): 
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1,  Touching      the       witon    in    the    'store'    causes    her    t> 
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2.  Touching    bj    i.i    the    •  pla>     aif'-a'     moves      the      'active 
square1    to    position    oJ. 
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After  touching  'move'  (resulting  in  the  four  arrows 
expanding  to  tour  single  'move'  commands)  ani  three  times 
th^    'move    rijfit'    command,    we   get: 
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2. 1.<4    Program    Writing    Mode. 
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h    the    Keyboard.) 


M 


ELJ_L£1_£  T  5  -cl 


^M 


■rr 


f 


■^^r^         &  &x 


Toy 

St    o    r    e  $@g 


$3® 


$ 

.%£ 

A 

^ 

4 

ou#r^ 

tf 

J 

T 


-00- 


♦GD* 


AVv; 


■00- 


n 


6 


out 


hanna 


I;] 


dr  ivljrte 


abede         fgh         i         j 


H  R  B  1  a  1 


itH 


flsf 


* 
oarr 


•naze 


2? 


Touching      i  h"      sauto   sequence   or    commands    is    in 
2.1. 1   completes   thv    program: 
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Fhe    child    can      then      store       th«      ^rograra       by      touchinj 
•wrap*      whicli    will    place   the    ii-irca    'run1     into    the    ' prcqram 
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2.'\.r>    Program    [execution, 


After  the  program  is  written,  touching  'ran'  (tlv* 
running  boy  at  the  bottom  of  the  screen)  causes  the 
commands  to  be  executed.  The  actions  will  be  the  same  as 
1  hoy    were    in    the    'immediate    execution'    mode.        (A      {<rogram 
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.  1 .  (i   Commands. 
"*. .  I.b.l    Language    Commands. 
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•  r  in  jor  box'  ri.s  i  re  m  in  lor  of 
the  lint  'store1  picture 
touch  oil.  (The         piet-uro       is 

still  symbolically  on  the 
ch  ill'  s    fin  -jer. ) 


•set ' 
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touched , 
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s  pace 


the 


a      dot.  ted 
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'drop'     --    list    'store'    picture 
touched    (the    one   currently      i:\ 
the      'finger      b>x*)     appears    in 
the    '  act  iv  *    s  m  ir*1 '  . 
(Fails       it  'active         square' 

occupied  --  s^e  the  descrip- 
tion of  'lojp'  lot  the  impli- 
cation of  failure  of 
comm  t  rid  s. ) 


mov 
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square' 
posi  tio! 


a  no. 

l  n 


moves  ' ac^ivo 

its  contents  one 
the  direct- ion 
indicate;!  by  the  arrow, 
(FiiL;  if  'active  square* 
empty,  destination  occupied, 
or    out sine    the    'pi ay    area'.) 

•move  active'  --  moves  the 
•active  square'  (without  con- 
tents) one  position  in  direc- 
tion   indicated. 

(Fails  if  hstiria*  ion  outside 
'  pi  (i  v    a  re.i  •  .  ) 

'eras1'  --  eraser-  contents  of 
•active    square ' . 
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Symbol 
-♦GD*- 

«-00-» 
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out 
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ijescri  ption 

•join*  --  .suporiifjoses  picture 
in  •  finger  box'  over  that  in 
the    'active    square'. 

'take  away'  --  negates  picture 
in  'finger  box'  from  onn  in 
'active  squire ' , 
dots       that       were 


the 


•  i- 


mger    dox 


i.e.  tunu 
turned  on  in 
off       in       t h  e 


1  act  iv e   square* 


•loop'  --  set  of  statements 
enclosed  by  'begin  loop'  .ml 
'.en  el  loop'  brackets.  When 
program  exacutioi:  encounters 
'end  loop',  control  transfers 
to    the    matching     'begin      loop'. 

'out'  —  transfers  control  to 
the  statement  immediately  fol- 
lowing the  'en  3  loop'  if  a 
command  within  the  'loop'  had 
failed. 


2*.1.b«2    5>ysten    Commands 
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•do  mod-.?1  --  invokes  'immedi- 
ate  execution'     noie. 

'write'  --  invokes  'write' 
uio.lc.  \  name  for  the  program 
is    l-'  j  uest.ej  . 

'wrap'  --  store:.,  the  program 
currenMv      La        the         'pro  g  r  a  ;a 

spac<  • . 

•run'  --  executes  the  pro. j  rati 
in    t.  he    'program   space'. 

'zap'  --  destroys  fhe  program 
in  the  'program  space1  and,  if 
it  In  1  been  stored,  its  copy 
i ri    th*»    'program    store*- 


2.1,7    f.  xa  in  pies, 

2.1.7,1     Bnv    Gets    RilLoons    an!    i  ises    with    The  .a. 
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The  co m ma n<]  'out'  will  cause  the  'program  pointer* 
to  exit  the  ' Loop'  (thus  ending  the  program)  because 
the  command  'move  up'  will  fail  when  the  top  of  the 
'play    area1     is   reached. 
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2.1.7.2    Dcawiiuj     i    City. 

Program      written    by   Linda    in    session   fS     (see    Appendix 
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•lir.r?':   'begin  loop',  'drop1,  'move  active  right*,  'out',  'en.l 
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2.2   observations   on    Programming   Concepts, 

,?.2.1    Alius    and    Methodology. 

The    aim    of    this    section    is       to      observe      how      children 
lc-ra      to      program.  tfe      tnink    that    children    make    better 

sul  jects  for  such  a  study  because  in  our  opinion  children 
'live  fewer  preconceived  notions  ot  what  computer  program- 
ming is.  Later  it  may  be  possible  to  apply  our  findings 
r  o    adults. 

'•'e  chose  to  dissect  programming  into  individual  pro- 
tramming  concepts.  The  concepts,  intended  to  apply  to 
iny  programming  Language,  are  listed  in  section  2.2.2. 
In  this  list,  concepts  not  in  <.'  AL  aie  omitted;  section 
1 . U  enumerates  the  reasons  foL  their  exclusion  from  PAL. 
Then,  in  section  3. 3,  we  will  relate  the  concepts  to 
the  experiments  with  children  to  determine  which  concepts 
are    easy    and    which    are    difficult    to    learn. 

I.  '->.  2    Enumeration    of    Concepts    in    PAL. 
2.  2.2,1    System    Modes. 

a.  Immediate    Execution. 

This   mode   is   available   with   many   interactive 
systems  such  as  A  PL  and  also  with  calculators. 

b.  Program  Writing. 

A  program  is  a  sequence  of  statements  designed  to 


3? 


i  >„ 


~>  .  7 


2.2. 
2. 


bo    executed    oy    a     processor. 
Editing . 

Procjra.ii    Execution. 
Mode   Chancjing.. 

2.2  MemoLy    aii'i    Data. 
Da  ta    v  ilnos . 

Data    can    take    on   values    of      "primitive      constants" 
(e.  g.  ii'i.ut   »rs)       or    "composite    values"    such    ^s    over- 

strikes    of      lines      on       printers      or      bac*  spacing       and 
o vcrstrik ing       (a:j    in    TUTOE    or    APL).        lata    values    also 
can    only    assune    "discrete   states". 
Variables. 

Variables   are    ".nemoty   cells"    or    "registers"      which 
roay    have    ro    be    "initialize!". 
Storage    or    Memory. 

Memory  can  be  "read-only"  or  "re » 1 /write".  To 
gain  access  r.o  memory,  ^n  "address"  roust  be 
s peci f iel . 

2.3  P  rogra  sis. 

2.2.3.1  So. j ue 'tee  of  Instructions. 

The  concepts  associated  with  a  program  dS  * 
sequence  of  instructions  are: 

a.  Static    sequence; 

b.  Dynamic    sejuence; 
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c.       Program    pointer; 
1.      Syntax. 

2.2.2.1.2  instructions. 

a.  Primitive  instructions  include  the  "assignment 
statement"  which  assigns  values  to  variables,  the 
"unconditional  transfer  of  control"  (e.g.  jump, 
goto),  "conditional  transfer  of  control",  "opera- 
tions" (e.g.  add,  conipi  re)  ,  as  well  as  addressing 
and  referencing. 

h.  Composite  instructions  include  "procedures"  which 
can  be  used  as  structuring  mechanisms  ol  as  exten- 
sions of  t.n.>  instruction  set.  Procedures  can  also 
be  predefined  such  as  square  root  functions  in 
FORTH  hV.  . 

"Loops"  (closed  sequences  of  statements  that 
will  be  repeated  a  finite  number  of  times)  are 
another  type  of  composite  instruction.  Both 
"loops"  and  "procedures"  can  be.  nested,  resulting 
in  new  composite  instructions. 

2.2.2.3.3  Determining  the  Correctness  of  Programs. 
Progrims  must  r>e  "debugged"   and   a   determination 

made  as  to  when  the  program  produces  the  desired 
results.  In  tae  process  ot  validating  a  program,  a 
"desk  check"  of  the  program  can  be  employed. 
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-1 .  1    iiow    PAL    Embodies    the    Programming    Concepts. 
>.  i.1    The  Overall    Structure    ot    PAL. 

PAL  simulates  i  computer  in  t  h  it  it.  presents  the  main 
parts  of  ;i  computer  an  the  PLATO  screen-  This  simulation 
i ^  geared  to  children  in  that  it  ls  entirely  pictorial 
ml  symbolic  and  is  designed  to  jive  children  an  under- 
standing of  what  a  computer  is.  The  com  man  is  the  child 
has  available  to  aim  are  visible  on  the  screen  at  alL 
times    as   a    reminder    of    what    he    may    use.  Ti;^      access      of 

those      commands      is      very   easy;    a    child    need    only    touch    a 
command    to    ev<».<«    it . 
\  1,2    Enumeration    or    Concepts, 
? .  3 .  2  •  1    System    ri ode  s. 

a.       Immediate    Execution. 

This  is  the  'do  mode'  which  is  invoke;]  by  touching 
the  'do  Diode*  command  (t^e  tointiny  hand  on  th"» 
bottom  or  the  screen).  After  this  mode  is  invoked,  a 
dotted  box  appears  a  ton;:  a  the  'do  mode*  symbol  and 
ill  subsequent  language  commands  which  are  touched 
are  immediately  performed  by  the  PAL  system.  If  a 
.stored  pi.ogra.ai  is  touched  while  in  the  'immediate 
execution'  mode,  it  appears  expanded  in  the  'program 
space'    au  '    cin    be    executed    by    touching    the    'run' 
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•v.'steffl      command.  (PAL      returns      to      tho       '  in  mod  iate 

execution'    mode    ifter    th:?    program    has   boon   executed.) 
b.      Progra  n    tfrit  in  j. 

The  'write  mode*  is  invoked  by  touching  the 
•  writ**"  systorc  command  (the  writing  hand  at  the 
bottom  at  the  screen)  f  it  which  time  i  dotted  ho;: 
appears    around    the    '  writa    mole'      symbol.  (A      dotted 

'ox  is  aLways  around  one  ot  the  system  mode  symbols.) 
A  mess dci"  requesting  that  i  program  name  be  chosen  is 
displayed.  The  name  may  be  any  cot  tin  at  ion  of  on«  to 
:our  characters.  Til*-1  name  chosen  hv  the  chili 
ippears  it  tho  ton  of  t ha  • program  space1  and  ill 
subsequent.       language      commands    touched    ni:o    written    to 


the       'program      space'       ana      form       -i       •program' 


i  he 


program  tuns  written  is  the  'current  program'  whicn 
can  be  Hini'  at  any  time  c /  touching  the  'tun'  system 
command.  While  in  the  'write'  mole  the  program 
currently  being  written  can  be  execute?.  After  t h » 
program  termini tes  the  system  remains  in  the  'write' 
mode  and  the  'current  program'  may  be  ad&od  to  by 
touching  further  language  com. nan  Is. 
c.   Program  Editing. 

While   in   tht   'write'   mode,   the   Last   command 
entered  into  i  'current  program1  cm  be  erased  by 
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pressing  the  -ERASE-  key  :>n  the  plato  keyboard,  A 
new  program  can  be  started  at  any   time   by   touching 

the  'writ*'  system  command,  at  which  tin  a  the  entire 
current  program  is  erased  and  a  now  name  is 
requested,  a  stored  program  may  be  edited  by  touch- 
ing the  'write'  command  and  then  touching  the  desired 
stored  program  when  the  name  >f  a  program  is 
requested- 

i.   Program  Execution. 

A  progra.n  in  the  'program  space'  (the  "current 
program")  can  he  executed  by  touching  'run'. 

(-.   Mode  Chan  gin  j. 

The  system  is  either  in  tie  'do'  or  'write'  mode. 
2  it her  can  be  invoked  ay  touching  the  respective 
editing  command.  A  program  may  be  'ran'  and  the 
screen  erased  from  either  mode.  A  program  may  bo 
deleted  (with  the  'zap'  system  co.amanl)  or  stored 
(with  the  'wrap'  command)  only  from  the  'write  mode'. 
<?.d.2.2  Memory  and  Data.. 

a.   Data  Va lues. 

The  primitive  constants  in  PAL  are  the  predefine  1 
pictures  located  in  the  'store'  and  characters  from 
the  keyboard.  (Pressing  keys  on  the  keyboard  his  a 
similar  effect  to  touching  the  pictures  in  the 
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•store1.  Note  th.it  the  children  Jo  not  need  keyboard 
skills  to  retrieve  letters  or  numbers  from  the 
keyboard  to  put  them  into  the  'play  area',)  Compo- 
site values  are  achieved  by  superimposing  primitive 
pictures  using  tne  '  join'  or  'take  away'  language 
a  a  iii  m  a  n  d  s . 

b.  Variables. 

Variables  in  PAL  are  the  individual  squares  in  the 
'  :>iay  area'.  Th(>  'finger  box1  is  ii.so  i  variable  and 
can  be  con-pared  to  a  register.  Erasing  the  '  play 
area'  initializes  the  variables  to  blanks.  The 
location  of  the  'active  sguare'  ani  the  contents  of 
the  'finger  box*  can  also  be  "initialized"  by  assign- 
ing values  to  them  ana  th^n  executing  a  program  that 
will  use  these  values. 

c.  Storage   or    Memory. 

The  'store'  and  the  predefined  or  'book'  programs 
represent  read-only  storage,  while  the  programs  writ- 
ten by  the  children  are  ^.ivzd  in  read/write  storage. 
The  'play  area'  is  also  rea d/wr 1 te  storage  which  is 
addressei  (as  is  the  'program  store')  bv  touching  the 
desired  location.  (If  the  'play  area'  is  touched  in 
the  'write  mode  * ,  the  cartesian  coordinate  represen- 
tation   o:     the    touched    location    is    written    to    the 
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•program   spice1.    The   child  net- 1  not  know  what  the 
cooed  incites  mean  to  write  or  understand  l!i<«  program.) 
> .  "-}.>.  3  I'roqi'i  ms. 

2.1.2.1.1  .ti'ui'Mice  of  Instructions, 
i.   Static  Sequence. 

Thf*  text  of  the  program,  its  static  sequence,  is 
displayed  in   th«-»   *  program   ppace1   both   while   a 
proqra;n   is   being   executed   ini  while  it  is  beirij 
w  r  i  1 1  e  v.   o  r  i  e  v  i  s  e  d . 
h .   Dynani  ic  So  j  uen  ce. 

The  flow  oi  control  (the  dynamic  sequence)  of   i 
program   is  indicated  by  d  'program  pointer'  as  the 
program  is  executing. 
c  .   P  r  o  a  r  a  in  Pointer. 

A  symbolic  'program  pointer '   represented   by   a 
hand   "points"   to   thr!  instruction  currently  being 
e  xecu  tel  . 
i .   Synt  u. 

The  syntax  of  PAL  is  extremely  simple.   The  only 
syntactically  incorrect  combination  ot  commands   is 
unmatched  'loop1  parentheses. 
2.1.2.  i.  2  instructions. 

*.   Primitive  Instructions. 
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The  "assignment  st  at  em  out"  is  explicitly  repre- 
sented by  the  'touch  store',  'drop',  'pick  up', 
'join',  'take  away'  and  'erase'  and  implicitly  by 
the  'move'  command,  'Touch  store'  assigns  th^ 
picture  toac:ne«3  to  the  '  finder  box',  'drop'  assigns 
the  current  'finger  box1  vai'je  to  the  'active* 
square'  while  'pick  up'  assijns  the  value  of  the 
'active  square'  to  the  •  tinge r  box*-  'Join'  an  1 
'take  iway'  also  alter  the  value  in  the  current. 
•activ »  square1  and  *er*se'  initializes  it.  The 
commands  'move1  and  'move  ictjLve'  change  the  posi- 
tion >r  iddress  of  the  'active  square'-  'Move' 
does  not  change  the  contents  of  the  'active  square' 
but    the    positions   in    the.     'play      area'       representing 


the      old       and      the      new    'active    sguar< 


The     'end 


loop'  cocaiand  is  an  "unconditional  transfer  of 
control"  mi  the.  'out'  a  "conditional  transfer  on 
control"  instruction-  'Pick  up',  'drop',  'move', 
•loin1,  'take  away'  and  'erase  '  are  operations 
while  'set  the  active  square'  (touch  the  'play 
area')  and  'move  active'  are  addressing  commands. 
b.      Composite    Instructions. 

•Loops'      and       procedures      are    composite    instruc- 
tions.      Procedures   are    use!    in    PAL    as    a    structurinj 
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mechanism  since  complex  PAL  programs  aro  modular, 
composed  ot  several  short  programs-  They  are  also 
extensions  or  the  instruction  cole  since  procedures 
are  incorporated  into  urograms  in  the  same  wav 
language  commands  are.  The  symbols  for  the  pro- 
grains  iro  stored  physically  near  the  commands  to 
help  the  caildren  remember  hoy  to  use  the  proce- 
dures. Predefined,  or  'book'  procedures  can  be 
used  like  the  programs  the  children  wrote  them- 
selves. 'Loops'  are  sequences  of  commands  enclose! 
by    'begin    loop'    and     'end    loop1       brackets.  'Loops' 

are  also  t red  ted  as  single  instructions  by  the 
program  execution-  If  control  is  transterred  out 
of  a  'loop'  (via  the  'out'  command),  the  program 
pointer  always  goes  to  the  instruction  immediately 
following  the  'end  loop'  bracket.  Both  procedures 
and  'loops'  can  be  nested  resulting  in  a  composite 
instruction . 
2.  .1.2. 3. 3    determining    the   Correctness    of    Prograras- 

Because  the  states  ano  memory  contents  of  the  PAL 
system  are  visible  at  all  times,  it  is  easy  for 
children  to  discover  ir  a  program  is  not  doing  what 
they    wanted    it    to.       One    way    of    finling    a    "bug"    is    to 
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point  to  cdcn  comma  nl  and  ask  tne  child  what  hn 
thinks  will  happen  when  PAL  executes  that  particular 
command.  This  process  is  easier  with  PAL  because  the 
•program  pointer'  is  also  a  hand  which  points  to  each 
command  i  s  it  is  executed.  Also,  the  PLAT0  screen 
contains  i  picture  of  the  system  parts  serving  as  i 
reminder  or  what  can  be  done  a  rid  where  things  can  be 
move1  ]. 
2.4    Common    Concepts    not    in    PAL. 

1 . u . 1    Oat a    Types    (e.g.       real    or    integer)  . 

PAL      has      only      one       lata       type       (picture    element)     for 
simplicity;    we    feel    that    is   sufficient    for      the      intended 
use    of    PAL. 
?.«'*.?    Data    3 1  r  u  c t  ur  es     ( e .  g.       ar  r  a y  s  )  . 

[{ere,      again,       ior      the      sake    of   simplicity    PAL    has    no 
structure]    data    types. 
2.4.^    Declarations. 

Data    declarations    are      not       needed      because      PAL      only 
roij  ports   °np    data    type    and    one    data    structure. 
2.4.4     I/O. 

This  feature  is  also  not  necessary  because  T/o  is 
needed  only  to  make  data  accessible  to  the  eye.  In  PAL, 
neinory    and    work    ar-aa    contents    .ire    always    visible. 
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?.u.s  Statement  Labels. 

Since   PAL   contains   no  "goto"  statements,  labels  are 
a lso  no t  needed, 
2.4.f  Procedure  Parameters. 

Parameters  are  not  present  in  PAL  in  order  to  keep  the 
system  simple.  An  etfect  similar  to  that  of  passinj 
parameters  can  be  achieved  by  moving  the  'active  square' 
to  a  position  where  tne  program  can  act  on  it  or  bv 
loading  the  'finger  box'  with  the  desired  contents  betore 
running  a  module.  (See  the  maze  example  in  appendix  E.) 
2.  4.  7  word  Lengt  h  . 

All  "words"  are  of  the   same   length,   therefore   this 
concept  is  also  not  needed. 
?  .  '4.  R  Counters. 

Because  oi      t'AL's  simple  loop  structure,  counters  are 
iiso  not  nee de i . 
2. 4. 9  Fecursion. 

Only  certain  limited  forms  of  recursion  are  possible 
because  PAL  has  no  procedure  paraue ters.  Also,  when 
writing  a  program,  its  name  is  not  yet  in  the  'program 
store1,  mar.ii  j  it  cumbersome  for  i  program  to  invoke 
itself.  Thus,  the  full  concept  of  recursion  is  not 
present  in  PAL. 
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\        Lx  poriments      to      Determine      how      Progra nutting      Concepts      arc? 
I.e. i  me  i, 
1.1    C;i.')«    Studies    in    Teachiny    PAL. 

1,1.1    Preliminary    studies   with   Several  Children. 

Three  children  were  used  in  the  preliminary  studies: 
Patrick,  age  12,  Jodi,  aye  11  and  ^ike,  also  11.  ML 
three  had  completed  the  fifth  grade  in  a  Champaign, 
Illinois    public    school. 

These  preliminary  tests  helped  us  understand  what  to 
look  tor  when  testing  children,  what  to  emphasize  in 
introducing  P\L  and  which  concepts  to  introduce  First. 
For  the  preliminary  session  we  deciied  to  work  with 
children  in  about  th*1  fifth  grade,  slightly  older  than 
the  children  PAL  wis  designed  lot.  Their  exposure  to  PAL 
consisted  of  i  totil  of  two  sessions  (see  appendix  C)  , 
but.  they  learned  to  work  with  the  system  quickly  and 
-•nloyod  programing  with  PAL.  One  ot  the  conclusions 
Leached  fro.n  the  preliminary  sessions  wis  that  it  is 
tetter  to  give:  the  children  little  help,  to  let  them 
experiment  o.\  their  own, 
3 .  1  .  '?    T  i  m  my    a  n  i    V  id e o    Ta  ping • 

At  the  start  of  the  sessions,  Tim  my  was  7  years,  6 
•months    old    and    in    thf*    second    grade   or     i    champaign. 
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Illinois    public    school.      John      Clement.1    helpel      with      the 
i  i:  tor  viewinq    and    introduced    Timmy    to    PAL. 

Pimmy  participated  in  12  sessions  which  were  video 
taped.  Sessions  3  and  0  weio  in  formal  with  no  instruc- 
tion and  were  held  at  Timmy's  school.  They  were  desicjnel 
to  let  Timmy  practice  with  PAL  or'  his  own  ind  proved  to 
he  quite  valuable  in  that  thsy  stabilized  Timmy's  know- 
ledge of  PAL.  The  later  sessions  were  further  apart 
which  hindered  Timmy's  progress  since  it  look  longer  for 
Tn:    to    rea quaint    himself    with    the    system. 

Timmy  was  often  fidgety  because  the  sessions  were  too 
long  for  someone  tnat  young,  but  shorter  sessions  would 
hive  been  impractical.  Several  improvements  to  PAL  were 
developed  from  the  observations  with  Timmy  (resulting  in 
version  2;  see  Appendix  A  for  the  differences  between 
versions  1  and  2)  . 
1.1.3    Linda    and    Audio    Taping. 

When  beginning  her  work  with.  PAL,  Linda  was  q  years,  1 
months  old  an  1  a  fourth  qrade  public  school  student  from 
t.  no  nortawest  sile  of  Chicago.  We  tried  to  utilize  the 
experiences  v,  ith  Timmy  to  improve  the  sessions.  One 
decision  was  to  use  a  child  slightly  oiler  than  Timmy  and 
to  try  to  hold  sessions  regularly  twice  a  week.  We  felt 
judio    tapes    alone    would    be    sufficient    since    we    knew    more 
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or  whit  to  Iook.  for  and  would  not  need  vi  Ipj  replays. 
Moreover,  audio  taping  would  provide  fewer  distractions 
to  Linda. 

one  of  Linda's  favorite  activities  was  forming  words 
on  t  lie  PLATJ  .screen.  When  she  arrived  at  home,  Linda 
tried  to  describe  PAL  to  her  family  and  was  very  happy 
when  she  was  given  a  picture  of  the  screen  layout  to  help 
with  her  descriptions.  According  to  her  mother,  Linda 
ruijoved  usin  i  PAL  ana  looked  iorwirl  to  her  sessions. 
After  the  tinal  meeting  Linda  had  the  opportunity  to  show 
nAl  and  the  programs  she  had  written  to  her  L  imiiy. 
1.2  Hapiple  Protocols  or  .Sessions. 


^h'3  transcripts  of  several  sessions  hav«>  Leen  picked 
is  samples  and  used  to  illustrate  the  progress  the 
children  mad'1  between  early  \  nd  later  sessions.  They  are 
Ixy  no  mean;:  meant  to  be  exhaustive.  Section  3.4  will 
reference  these  sessions  where  applicable. 

Each  protocol  i  :i  this  section  is  introduced  by  the 
session  number,  b  y  how  many  minutes  had  elapsed  and, 
where  relevant,  what  had  occurred  to  that  point.  The 
protocols  appear  in  two  columns,  the  left  is  the  tran- 
script of  what  way  sail  (the  actions  ar*-  iescriLed  in 
parentheses)  and  the  right  column  our  observations  on  the 
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occurrences..  An  -H-  in  the  right  column  indicates  that. 
Mm  child  rccelvel  help  it  that  point,  -ii-  that  a  mistako 
wis  nade  and  -I-  indicates  the  chiLd  had  an  idea   of   his 
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\.?..'\    Tim    --   So  so  ion    c> : 

Tiramy    Gains   a    Clo.irei    ;J  nde  rst  a  nd  i  no    of    P  ro  gramm  in  q. 

In  session  *5  Timmy  star,  tod  out  being  vory  unsure  of 
program  writing.  John  provide  1  extensive  help  with  the 
first  program,  and  later  in  the  session  Tim  wrote  one 
with  verv  little*  help  using  the  commands  'cove'  and 
'loop'.  To  thin  point  ho  nad  been  exposed  to  PAL  for 
three,  hours  4?  Minutes  and  to  writing  programs  for  a 
total    of    two    hours,     20    minutes. 


A 

KT 

/■> 

c:    rip  t    : 

ii'^i ;. 

n  i  ■ 

l  ■: 

ofc    session    r> 

( T i.  m r. y  drew  pictures  on  his 
v«?n  while  John  and  Ha  una 
readied  the  video  machine. 
After  7  :ninut«s,  Tim  touched 
the  'write  '  system  command  and 
asxed  John  how  to  spell 
•city'.  Ti  ni  then  named  his 
program    'city'    and    asked:) 

'low    what    do    T    do? 


What     lo    yon    want    to    do? 

T    want    to  writo   a    program 
rut    7    to  root    what     i    dj. 


Timmy    is    very      guick 

to  ask:  "what  do  T 
do  now?"  He  needs 
hints  along  the  way 
at  this  stage  and  is 
unsure    of    himself. 


J:  OK,  what  would  you  like 
the  program  to  lo  rihrtn 
yo u  •  ro    d one? 


-H- 


r:       i*'alk.       tfalk    up    and    down. 

J:  Then  w-»  touch  the1  things 
we  would  touch  to  a .1  ,\e  the 
I   •  rsoi.         walk  ,         .or,  L  y  ho 

doesn't  walk  right  away, 
1 1-.  ■»  y  jiiot  corae  ov«r  here 
(John      points      to    the    '  pro- 

1  r  j  .;     ;;  L  oi  '  )  . 


Tim   seems   to   know 
what  program  can  do. 

-li- 


re 


John 


rev  lews 


the 
a 

co  m mauds. 


idea  of   writing 
sequence    of 


u  f\ 


'•'hit    do    you    rae.-ii: 
i    pi  ico    anywhere? 


T    touch 


Yea,  you  h.ive  to  y^t  some- 
body. You  should  probably 
uick  him  up,  wnoev»r  you 
want    from      the       'a tore1       to 

W  A  1  1  . 


John  is  trying  to 
give  Tim-  a  hint  to 
program  the 

sequence:         'store', 

'pick  up',  'set  play 
area',  Mrop';  Timmy 
is  not  responding  to 
the    hints. 


Z\v,    I    make    two    things    walk 
at    the;    same    tine? 

'That's  harder  but  you  can 
io  it.  tfhy  don't  we  make 
of)-'  person  walk  a  nil  then 
I'll  show  you  how  to  put 
the    other    person    in. 

OK.  I'll  oiako  him  walk. 
("in  touches  in  the  'play 
i  r  e  a  '  ,  k  A  a  p  pe  a  r  s  i  n  the 
1  pro  jtri.il    space'  . ) 

■:  h  it  h  a  ppened  ? 


Tim  is  thinking  of 
pr og ramming  to  ma k^ 
pictures  move,  not 
of  *  pick  up'  a  ni 
Mrop1  commands.  He 
is  not  paying  atten- 
tion to  John  's 
leads,  ?im  wants  to 
figure  out  what  to 
io  cy  himself.  tie 
is  gaining  conri- 
dence  with  PAL. 


-M- 


7t  does  " ka",  (Tim  pauses 
to  think)  I  wuit...  ( ? i m 
touchoo  different  squares 
in  the  'play  ar^a'  and  sees 
the  coordinates  appear  in 
the     'program    space'.) 

J:  So  why  don't  Wk!  pick  up  a 
person    to    do    the    talking? 

T:  That    one.       (Tim    points    to 

a  jirl  holding  a  t lower 
which  he  previously  put 
into    the    play    area.) 

.7:  ^irl  with  a  flower?  OK, 
then  why  don't  we  maKe  her 
go    up?       Will    that    be       good? 

:' :  yea,  that's  what  I  want  to 
io. 


Tim         is         used  to 

'immediate  execu- 

tion •  mode  and  is 
wondering  why  th3 
Mctive  square' 

ifin't  appearing  at 
tne  spot  he  touched 
iu      the    ' play    area '. 


Tim  my   knows    which 
picture  he  wants. 
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Then      lot's      put      the    box 
arou nd    t  he    girl. 

Ciiiti!  y         touchPo         girl 
eiasf-s      the      entry      in      the 
pro  gram   -    touches  again) 

Mow,  "im,  when  it  says  iA 
hero  (joints  to  the  iA  in 
the  'program  spac-3')  -  see 
the    i  A  ? 


Here  Tim  forgot  how 
"touch"  works  while 
in  the  programming 
mode,  he  is  expect- 
ing the  • act  ive 
square"  to  appear 
where    he    touches. 


iO-(    m 


Ldtnr  on,  when  we  push 
nir.,  when  the  arrow  (the 
r Log  Lam  pointer  was  an 
arrow  in  version  1)  cones 
no  wis  the  program  and  it 
-i'p:;  the  iA,  it  will  put 
th  e  hox  {the         • act iv  e 

square')     around      the      girl. 
So    tha t • s    good  . 

ijiidt    will    she    do,    go    up    or 
down? 

N'o,  she  isn't  join j  any- 
where yet,  cause  wc  didn't 
put  any  arrows.  So,  maybe 
we  oetter  get  some  arrows. 
'■'  n  ij  h      w  ay      do   you    wa  n  t    he  l 

to      JO? 

wan  t  her  to  go  ... 
(touches  the  'move  up1  six 
tines,  then  the  'moves' 
1  eft ,     lown    and    right) „ 

tfoul-1    you    like    to    try    it? 

(";"i       touches         the         'move 
down'    two    more    times,) 


Tim  my  isn't  thin  kin  j 
a  ;>  o  u  t      h  o  w    a    pr o g r  a  m 

wor  ks.  He         nee ] s 

more  practice  witn 
p r  o g  r a  m ,u  i  n  q  to  q e  t 
used  to  thinking 
i:)out  commands  which 
are    stored       and       can 


executed      at 


he 

later    time. 

Because  Tim  still 
isn't  getting  t  n  a 
idea  or  programminj 
r.  h  e  'pick  up', 

• d i op'  segue  nee, 

John  goes  along  with 
Timmy ' s  train  of 
though t. 
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J: 


J: 


J: 


.:«,    push    the      Lunnini       boy 
to       make    it    do    tho    program. 

(Tit,       touches         'run*  and 

wdvns  his  hand  over  the 
.screen  in  a  circular  motion 
as  the  program  executes  and 
the  girl  moves.  At  this 
point  the  program  consists 
o*  the  statement  "iA"  and 
11     ' n  o  v  e  s • - ) 

It's      going    down    the    pro- 
gram,    isn't      it?         See       the 

arrow?  It's  going  right 
down    the    program. 

Can    T    make   it    run    again? 

Yea,     let's    do    it    again. 


(7  i  in    touches       '  run  ' , 


messages 


appear. 


error 
Since 


her 


is      now      nothing      at 


location 
fails.) 


iA, 


Lh< 


ui  o  v  e 


•!hat       happened? 
box?  (Poirts 

•active      square' , 
]  ocat  ion    iA. ) 


See  the 
to  the 
now         at 


Timmy  is  overjoyed 
to  see  the  girl  move 
the  way  he  had 
directed    her    to. 


Ti  m      d 
stand 
s  j  ua  re 
around 
since 
that    t 
mind 
wis 

s  ]  u  a  r  e 
(The 
before 
execut 
progra 


oesn ' 

why    t 

wa 

th 

he 

he    £  i 

in    hi 

"  move 

to    t 

girl 

th 
ion 
ra.) 


t  under- 
lie active 
sn't  put 
e  girl 

thought 
rst  cor 
s  program 
active 
he  girl", 
was  at  i A 
e  first 
of         the 


I 


ant    it    to    move 


J:  It  (the  error  message) 
says,  "that  command  railed, 
there  is  not  hi n ]  to   move". 


(  t  i  m  m  y 

w  i  t  h   a 

sg ua res 

'  ictive 

the    program 

execut  ing   an  1 

in  turn  ta  ils. ) 


t  ouches 

flower, 

higher 

square ' . 


the 
now 
tha  n 


girl 
two 
the 


Mean w hi le 


is 

each 


still 
move' 


No  w  hv  * r,  manu  ally 
trying  to  place  the 
Mctive  sguare' 
around  the  jirl,  not 
realizing  that  the 
commands  will  not  be 
•immediately 
executed1  while  the 
program   is  running. 

-H- 
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See      that 
( points         to 
poi nt«r) ,    Tim? 


ai_row        there 
the      program 


t  e  i . 


Tt  (the   progr 
counts  ah']  sees 
arrows.   It  com 
to   move   what ' 
(*  act  ive    squa 
Mi  ere '  s  no  th  ing 
So  T  guess  the 
works   whon   we 
thing   there 
] oci t ion  LA)  to 
a  "-  cai:  pit  some 
(Joh n   brief  Ly 
'  imm  of]  latt  exec 
and  helps  Tim  e 


im  pointer) 
one  )f  these 
es  an (3  wa  nts 
.-,  in  the  uox 
re' ) ,  but 
in  th  a  box  . 
program  only 
have  some- 

(pO  Lilt  J     to 

start  with. 
thin  j  there, 
o  x  p  1 1  i  n  3  t  h  o 
:i  tion*  mode 
v o  k e  it.) 


(Timmy  puts  in  umnrelld 
from  the  'store'  into  posi- 
tion i  A  and  erases  the  girl 
v  it  h    t  lower.  ) 


M  o  w 
w  o  r  k 


think   'city'   will 


Here's   city   (points   to 


stored    program 
touching   it ) . 
the  program  bac^ 


without 

If   we  get 

f  o  r   city 


John  briefly  r  e  v  i  e  w  s 
program  execution; 
TitRiny  nee  is  frequent 
repetions  of 
explanations. 


-M- 


Ti m  did  not  get  a 
systematic  introduc- 
tion to  modes  a n 1 
mode 


c  h  a  n  g  i  n  j 


previously. 


At       this      point      Tim 
doesn't  carefully 

think       through      what 
he      does,       but,  we 

feel ,         is         gainin  j 
correct  intuitive 

feelings      about    what 
may    work. 


Oh ,     T    k  now 
do.         We      run 
(touches 
wait  in g 


no th  i ng    ha  ppens) 


what    wo    need    to 

i  t ,    don't    we  ? 

•run'  without 

for    ax      answer. 


Mere  Tim  is  begin- 
ning to  get  the  idea 
of  what  it  means  to 
execute  a  program. 
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J:  Pus}  'city1.  You  nave  to 
push  city  tirst  to  toll  it 
uh.it  to  run.  (John  touches 
•city'  in  the  'program 
store',  then  'run'.)  Here 
cones  the  program,  there 
s he         go >js .  (T h e      p c og  ra  m 

moves    the    umbrella.) 

(At  this  point  Tim  my  starts 
a  new  program  --  not 
transcribed- ) 


T  i  m  m y  Knows  that 
'run'  executes  a 
program,  but  has 
difficulty  realizing 
that  the  'active 
square1  must         be 

-irouni  a  program 
before  it  can  be 
'run'.  (This  is  not 
necessary  in  version 
2.) 


I  got  an  idea,  (Tim  puts 
girl  an i  umbrella  in  iA 
using  thn  'immediate  execu- 
tion'   in  o  1  e . ) 


-I- 


Can  we  nake  her  jo  up? 

'fea  (Touches  'city',  then 
'  i.  un)  . 

(The  proqram  executes  and 
moves  the  giri  wit  a  the 
urn  brella! ) 


At   this   point    it 

seems  as  if  Tim  my 
knows  how  to  exec  at? 
a  program  that  has 
oeen  stored. 


'J.'int  a  puzzle?  I  got  a 
problem  for  you.  (John 
erases  the  'play  area'.)  I 
want  you  to  see  if  you  can 
make  a  program  to  ...  If  I 
put  a  car  over  here  (John 
puts  a  car  into  location  a A 
of  the  'play  area'),  can 
you  do  a  program,  Timmy,  to 
make  a  c  ir  move  over? 

'low  m  \]\  v? 

i"cr  to  F  (position  iF). 

I'll  try  to.  Do  I  hive  to 
name  it? 


Tin  my  needs  to  be 
given  ideas  and  he 
quickly  picks  up  on 
them.  Idea  seeds 
from  adults  were 
valuable  in  that 
children  could 
expand  on  them.  In 
a  classroom  situa- 
tion children  giv;> 
oicn  other  ideas. 
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J :  Yf.i,  in  order  to  writr  the 
pro  I  ram,  you  have  to  push 
'write'  . 

(Tim  touches  'write',  names 
bis  program  and  touches  a A 
as   the  first  instruction, J 


John  repeats  the 
instructions  for 
beginning  a  program; 
Tim  needs  frequent 
reminders. 


a  A ,  that's  wherp  you 
i  t  ? 


want 


J:         Yea,       that's      where    it    is 
(the    car    is    located    at.    aA)  . 


!qw    what    do 


do 


(before 


he    completes    the      question, 

'  move    rigli  t ' 

thou       'run'. 

executes      a nd 

one   position 


Tin;   touches  6 
commands   and 

The  urogram 
the  car  joes 
too  car.) 

Farther ! 


J:  Hissed  by  one!  Can  we  fix 
if?  What  will  we  have  to 
do  to  only  make  it  jo  to  f? 

(Tin'  nresses  the  er  ise  key, 
thereby  erasing  the  Last 
'move'  in  the  program. 
Without  testina  the  pro- 
gram, Timiny  touches  'wrap* 
to  store  it.  ) 


Asking   what 
seems  to  be  a 
with   Tim. 
does  know  wha 
and      demon 
that  he  can, 
h .?  1  p ,   /rite 
gram  consisti 
starting  posi 
the  'play  are 
'  tio ves  '  which 
the   contents 
starting  posi 


to  do 
habit 
Mere  he 
t  to  do 
st rates 
with  no 

a  pro- 
ng of  \ 
t  i o  n  in 
\  *   a  nd 

act  on 

of  the 
tion- 


Here    ?in>my    seems 
sure  of  himself. 
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3.  ?.-?.    Tim    --   Session    14: 

rim  my    Debugs    ero^rams   a  nci    Uses    Loops. 

In      this      session      Timmy  wrote    a    program    using    'moves* 

contained    in    a    'Loop',      and  used      the      program      to      move 

several    different    pictures.  lie    had    been    writing    programs 

for      B      hours    over    a    period  of    5     1/2    months    prior    to    this 
session. 


!_?_ A_M_ J_C_ R_I _P_T_l . 

jr)  ininuf.(-s  into  session  1U. 

T:   I  can  make  that   witch   go 
(points  to  a  witch  superim- 
posed or.  a  car  in  the  '  pia  y 
area  ' )  . 

J:   whore? 


Hare  Timmy 
idea  for  a 
by  himself. 


-I- 


gets  an 
program 


T:  hack  and  forth,  \ o  you 
want  to  see  it  ? 

J:   Yes. 

(Tim  touches  'write',  names 
f'ne       program         'rfty'  and 

w  r  i  t  es  the  command  s:  '  move 
right1,  'move  left',  witch, 
'drop1,    fD.) 

T:       And    that' 11    work. 

.1 :       >:hdt    will    it    do? 

r:  Tt'l]  move  it.  back  and 
forth.        I    bet    it    does. 

J:  what's  gonna  make  it  go 
back    and    forth? 

T:  "hat  little  (points  to 
'move'  commands  in  the  pro- 
gram, then  touches   'run'). 


Timmy  doesn't  need 
prompting  at  this 
point. 

-H- 

Tira  writes  the  pro- 
gram quickly,  impa- 
tiently; he  doesn't 
think  about  indivi- 
dual  commands. 


He  sees  arrows,  a 
witch  and  'drop*  in 
his  program         and 

doesn't  think  about 
the    order. 


Tim  does  know  what 
the  'move'  command 
will  do,  but  doesn't 
put    it    into    context. 
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(The  program  executes  and 
since  tho   'active   square1 

is  around  the  witch  in  the 
•play  area',  the  witch 
moves  back  and  forth  once.) 


ok,  it  did  at.  the  begin- 
ning there-  Oops.  (Execu- 
tion of  the  'drop'  results 
in  ^n  error  message  since 
the  'active  square'  is 
occi]  pied . ) 

Heh. 


John  tries  to  guide 
Tim  through  steps  of 
debugging-  Tim 

doesn't  want  to  take. 
time    to    analyze. 


OK, 
p.  rroi 
went  hick 


o    we    got    a    couple    of 
messages      after         it 


and  forth  once. 


Right. 

Nov       why       did     it    do    that, 

Tim!ii  y  ? 

T    don't    know. 

Stop    a    minute.       I'm      gonna 

ask       you.         What      happened? 

[Tiromy    was    about       to      touch 

the         screen       in       order      to 

change    his    program.) 

Should  have  put  that  first 
( points  to  the  second  part 
of  the  program,  the  witch, 
•drop',  fD). 

Oh,  all  the  stuff  to  get 
the  witch  and  th"  car. 

(Tin;  prases  his  pro; ram  and 
substitutes:  'bog in  loop', 
'move  right',  'move  left', 
' end  loop1 . ) 


Timmy  is  still  guick 
to  say  that  he 
doesn' t  know. 


When  John  pins  him 
down,  Tim  does  know 
why  the  program 
tailed  ,  at  least 
generally- 


-I- 


I    bpt    that'  11    work. 
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J:  UK,  what  do  you  think 
that'll  do   before   wo   run 

it? 

T:  Ft  hits  that  loop  and  goes 
that  way  all  over  (points 
to  'oti.l  loop'  and  then  back 
to  ' begin  loop* )  - 

.1 :  And  what  will  it  do  on  the 
screen? 

7:  iUldke  the  witch  jo  back  and 
forth  on  the  car. 

■J:  flow  long? 

T:  \s  lonq  as  I  want  it  to. 

J:  Really? 

T:  Yea. 

J;  OK,  here  goes,  we're  gonna 
run  it;  (Touches  'run', 
pause)  back  once  --  what's 
h  a  n  p  e  n  i  n  g  ? 

T:   It's  going  back  and  forth. 

J:  (Claps)  He  solved  the  pro- 
blem --  I  told  him  I  bet  he 
couldn't  do  it,  that  he 
couldn't  make  the  witch  go 
back  and  forth  on  the  car 
forever  and  ever. 

How    long    do   you   think 
that'll  go,  Timmy? 

T:  As  long  as  --  it  can  do  it 
all  night.  I  bet  if  we  go 
down  an!  have  a  pop  and  we 
get  back  that  thing  will 
still  be  doing  it. 


Timmy  still  writes 
programs  without 
analyzing  them  very 
well,  but  he  has 
more  of  a  feel  for 
what  they  shoull 
look  like,  for  the 
s^guence  the  com- 
mands should  appear 
in. 


Tim  added  the   loops 
with  no  help. 


-I- 


Here  it  seems  that 
Timmy  displays  an 
understanding  of 
loops  and  the  abili- 
ty to  analyze  com- 
minds   in  a  program. 


A    very  definite 

answer.  Tim   seems 

very  sure     of 
himself. 
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J:   And  not  yet  t ited? 

T:    Uh,  ah  (shakes  his  head). 

J:  OK,  question.  What  Jo  you 
have  to  do  it  you  want  the 
tree  to  go  back  and  torth 
like  that? 


Hare   Timmy   appears 
to  display  an  under- 


standing 
important 
about 
that  they 
on   doing 
ate  told 


of     an 

concept 

computers, 

will   keep 

what  they 

to  do. 


T:   Same  thing. 

J:    Can   you   do   that    real 

quick? 

T:  Yes,  watch.  (Tim  touches 
tree,  which  put.--,  it  at  the 
end  of  the  program,  i.e. 
the  program  is  now:  'begin 
loop1,  'move  right* ,  'move 
left1,  'end  loop',  tree.) 

T:   OK  ..-•  no,  that  won't  work 

(erases   tree,   stores  the 

program    and    goes  into 
'immediate  execution'  mode: 

puts   a  tree  into  play  area 

and  touches   'run'   --  the 

program   now  moves  the  tree 
back  and  forth) . 

J:  before  you  hid  a  witch 
over  here  on  a  car  and  rfty 
(Tim's  program  name)  was 
moving  the  witch  back  and 
forth.  Now  you  have  a  tree 
here  and  it's  moving  the 
tree  back  and  forth. 
Timmy,  before  you  touch 
anything  more,  I  got  a 
question  for  ycu.  (Tim  was 
about  to  touch  the  screen.) 


W  hat. 

Is   there   anything 
this  program  can  do? 


Again,  Tim  writes  a 
program  very  quick- 
ly, but  he  is  get- 
ting a  better  feel- 
ing of  what  sequence 
of  commands  to   use. 

-I- 


Timmy  is  more  confi- 
dent about  changing 
modes,  and  executing 
prog  rams. 


He 
an 


is  also  showing 
understanding 
about  how  a  program 
works,  that  it  can 
act  on  the  contents 
of  the  present 
' act  ive  square1 . 


Tim  is  fidgety, 
anxious  to  try 
things  out.  He 
wants  to  make  things 
happen,  experiment, 
not  analyze. 


else 


S3 


T:   Let  roe  think. 

J:  Before  it  was  working  with 
a  witch,  now   it's   working 

with  a  tree. 

T:   No. 

J :  It  can't  make  anything 
else  move? 

T:  Yei,  most  everything. 

3  :  \   helicopter? 

T:  Yea. 

J:  Smoke? 

T:  Yea. 

J:  Anything  else? 

T:  Yea,  everything. 

J:  Oh,  OK. 

T:  I  could  probably  make  a 
girl  on  a  bicycle  go  back 
and  forth  and  -- 

J:  You  sure? 

T:  Uh ,  h  u  (nods) . 

.1 :  what  makes  you  sure? 

T:  Well,  I  just  know. 

.7:  Could  it  make  something  go 
up  and  down? 


Timmy  misunderstands 
what  John  means.  He 
thinks  John  wants 
the  program  to  do 
something  other  than 
make  the  contents  of 
the  'active  square' 
jo  back  and  forth. 


Mere  Tim  seems  clear 
about  what  the  pro- 
gram does  but 
doesn' t  want  to 
describe  the  program 
step  by  step. 
Again,  he  is 
impatient. 


T:   Ye»- 
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J:   You   just   put   the  witch 

here   and  what  would  you  do 

to  make  the  witch  go  up  and 
do  wn  ? 

T :   I'll  show  you, 

J:   ok. 

T :  I'll  make  the  tree  j o  up 
a  n  d  d  o  w  n  . 

(Tiir,  starts  a  new  program 
consisti ng  of:  'begin 
loop',  'move  up',  'move 
down',  'end  loop',  'exit1; 
and  touches  'run'.) 

T :   It's  working! 

J:   it's  going  up  and  down? 

T:   Yon . 

J:  Far  out!  --  Does  this 
exit    do    anything,    Tim? 

T:       Yea. 

J:   What  does  that  do? 

T:   When  it  wants  to  stop   it, 

it  is  on  the re- 
el:   When  it  wants  to  stop  it, 

what  ? 

T:  Vhen  you  got  the  loop 
started  going  like  straight 
across,  wh^n  it  gets  to  the 
rr.d  it  stops.  That  arrow 
(program  pointer)  stops  so 
it  won't  say  that  command 
failed. 


When  faced  with  the 
problem  of  making 
things  go  up  and 
down,  Tim  realizes 
that  he  has  to  write 
a  new  program, 

-I- 

de  feels  confident 
in  writing  the  pro- 
gram, but  is  plea- 
santly surprised 
when  it  works. 


-In- 


putting the  'exit' 
in  the  wrong  place 
is  a  minor  error. 


He  does  appear  to 
understand  the  prin- 
ciple of  ' loops' , 
•exits'  and  of  pro- 
gram pointers. 

-r- 


Whit       would    happen    if    you 
didn't    havo    the    'exit'? 
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It  would  say  t ho  command 
failed  for  a  long  time; 
till  I  go  " ba  c  k ,  back, 
bick"  (presses  the  -BACK- 
key  which  stops  the  program 
o  xpc  ution)  . 

(John  explains  that  the 
'exit'  has  to  be  inside  the 
•loop'.) 

Could    'rfty'    make  the    tree 

go         all      the      way  across? 

Cause  then  you'd  really 
need    the    ' exit  * . 


He  has  the  idea, 
even  though  he  can't 
verbalize  it  very 
well. 

Here  Tim  shows  that 
he  knows  how  to  get 
out  of  a  loop  by 
interrupting  the 

program   execution. 


-I- 


(Tim    erases    his    pLogram    and 
writes  the  commands: 

'begin    loop',       four      'moves 
right',  'exit',  'end 

loop'.) 


Now  Timmy  doesn't 
hesitate  in  writing 
a  program  and  shows 
confidence  that  the 
program    will    work. 


J:       Now    before   we    start, 
will    it    do? 


what 


Do  like  you  told  me,  watch 
(touches  'run') . 
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3.2.3    Linda    --   Session    2: 

Linda    is   Introduced    to    Programming, 

In  this,  Lindi's  first,  exposure  t.o  program  writing, 
she  gradually  learned  to  write  a  program  which  put 
pictures  into  the  'play  area'.  She  was  confident  in 
using  all  commands  in  the  •immediate  execution'  mode  and 
had    been    exposed    to    PAL   for    ohe    hour. 


TRANSCRIPT 


4f>j  inn  j_nj_of_sessi_on_2. 

(Linda  drew  pictures  tor  12 
minutes  after  whic.i  time  Hanna 
introduced  the  concept  or  pro- 
gramming. Atter  the  dif- 
ference? between  'do'  and 
•write'  modes  was  explained, 
Linda  touched  'write'  and 
naiT.  ed         her         first  program 

'  t  i  n  a '  . ) 

H:   Try  something. 


You  mean  like  I  touched  a 


car . 

H  :  Yes,       go       ahead, 

touches         a         ca  r 
'store '. ) 
Now    what    happened? 


(Linda 
in   the 


Linda  is  hesitant  at 
first,  she  doesn't 
seem  to  understand 
the  explanation  of 
'program',  she  needs 
to  experiment  with 
the  concept  herself. 


L:   The  car   went   over   there 
(points    to   the   'program 
space')  instead  of   in   the 
box  (  '  f  i  nger  box  ' ) . 

(Hanna  re -explains  the 
meaning  of  a  program  and 
that  Linda  is  now  writing 
one.  Linda  touches  bicycle 
and  vw.  After  Hanna 
explains  how  to  run  a  pro- 
gram, Linda  touches  'run'.) 


Jhe  does  see  that  a 
program  is  being 
formed,  but  not 
guite  what  the  pur- 
pose is. 

-H- 

ilanna  again  explains 
the  difference 

between  'write*  and 
'do'    modes. 
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Vow    what    happened? 

The  things  that  T  out  down 
(into  the  program),  the 
hand  ('program  pointer') 
went  to  thorn  and  lp pea  red 
thorp  (points  to  the  'fin- 
gee    box ' ) . 

(Hanna    explains      whit      hap- 
pened   and    what     •run1    does.) 


Linda  does  see  a 
relationship  between 
the  things  she  did 
earlier  and  what 
happened  after 

touching     'run'. 


l:  Before,  when  the  dotted 
box  war,  arouni  the  hand 
(the  'do  mode'  syinlol)  ,  how 
would  you  put  something  in 
the    play    area? 

L:  I  would  touch  one  or  the 
pictures,  then  toucn  where 
T    wanted    it. 

H:      OK,    why   don't    ,-ou    try      it. 

L:  OK  (touches  the  house  in 
the    'store') . 

H:       Then    what    wouli    you    do? 

L:  Then  I  would  touch  the 
'drop'  and  it  would  come  in 
here  (touches  the  'active 
sguaro  • ) . 

\\ :  Co  ahead  and  try  it. 
(Linda    touches    'drop'.) 

L:  It  won't  do  that  because  I 
have    the    program 

H:  It  won't  do  that  now,  but 
we  can  make  it  do  that 
lat.^r,  anytime  wo  want  to 
by  pushing  'run'.  Push  the 
'run'  and  see  if  it'll  do 
t  nar  . 


Here  Linda  does  not 
]uite  understand  the 
relationship  between 
the  commands  in  the 
'immediate  execu- 

tion' and  'write' 
modes.  She      needs 

practice  to  see  for 
herself  what  a  pro- 
jram    does. 


-H- 


Linda  seems  to  un- 
derstand that  writ- 
ing a  program  means 
that  the  commands 
won't  be  immediately 
executed,  but  not 
why  one  would  want 
to  do  that. 
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(Linda  touches  'run',  the 
program  ' t i  n a ' ,  consisting 
of  douse  and  'drop'  puts  a 
house  into  the  square  which 
is  currently  active  in  the 
1  pla  y  area  '.  ) 

There  it  goes!  Either  you 
can  add  to  this  program  or 
do  something  else.  What 
would  you  like  to  do? 


Linda  wrote  the  com- 
mands on  her  own, 
but  not  the  program 
since  Hanna  gave  her 
bints  to  use  the 
same  commands  she 
wjuli  use  in  the 
'immediate  execu- 
tion ■  mode- 


Ad  1  somet  hing- 

OK,  jo  ahead,  try  it. 

(Linda  adds  car,  bicycle, 
Vrf,  sun,  'drop',  tree, 
umbrella,  'drop'  ml  slower 
to  her  program.) 


She  appears  to  enjoy 
programming  since, 
when  given  the 
choice,  she  wants  to 
continue  with  her 
program. 


(Hanna   erases 


nf 


play 


area'  by  touching  'broom* 
and  Linda  touches  'run'. 
Kheri  the  program  executes 
the  second  'drop',  a  fail- 
ure message,  that  "Th^re  is 
already  something  in  that 
space" ,  appears.) 


Linda  is  not  sure 
what  the  commands  in 
a  program  mean,  but 
she  sees  that  they 
appear  in  the  *  pro- 
gram space'. 


Why   is   it   saying 
command  failed"? 


"That 


Because         I 
1  1  r  o  p  s  '  . 

Can't         you 
' drops' ? 


have         two 


nave 


two 


Mere      she        analyzes 
programs    a    little. 


No. 


H:      Why   not? 


L:  Because    then    if     T    hid    one 

hero  to  put  th<j  sun  down 
and  if  I  had  this  here  it 
won't  put  the  witch  djwn  in 
the    same    nox. 


Let 


try      another        one 


( p  rojnrn), 


OK 


3  u  i  s*-!    that 


one.  (Shows  Linda  how  to 
erase  the  commands  in  her 
program  by  pressing  the 
erase  ke  y)  - 
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She  associates  the 
meaning  of  a  'drop* 
in  a  program  with 
'drops'  she  is  fa- 
miliar with  in  the 
'immediate  execu- 
tion' mode. 


(Linia   wants   to 
'play  area  '  .) 


f>rase    the 


Now    how    do    you  jet       it       to 

erase?          (Linda  touches    the 
picture    of    an      eraser,       the 

•erase'    command  is    added    to 
the    program.) 

It     iidn't    erase  the    screen, 
did    it? 


Here  Linda  is  learn- 
ing the  differances 
between  the  'write' 
and  'immediate 

execution'         through 
practica 1 
experience. 


No, 
you ' re 


(  'immediate 

mode) . 


cause  that's  when 
drawing  a  picture 
execution' 


Do    you    think    you    can  tell 

the    computer    to    put    a  house 

h^re         and         a      girl  there 

(points         to         the  'play 
area')  ? 

(  V3    second    pause) 


-H- 


Weli,  before,  when  we  were 
just  doing  it  without  writ- 
ing a  program,  how  would 
you    put    a    house    here-? 

By  touching  theie  (touches 
in    the    '  play    area' ) . 


flere  Marina  didn't 
have  to  tell  her  to 
"go  ahead  and  do 
what  you  would  do  if 
you  were  drawing  the 
picture  in  the  'do' 
.node". 
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H: 


What  happened? 

oA  went  ii.  the  program. 

(Hann^  explains  what  the 
coordinates  mean.) 

Then  what  would  you  do  to 
put  a  house  there? 

(Touches  the  house)  and 
the  house  didn't  tjo  there 
because   it's    remembering 

(the  program  is  remembering 
and  not  "doin j"  the 
commands) . 

Is  that  all   you   nave   to 
do? 

Yea,  because  wh en  t ho  hand 
(program  pointer)  comes 
here  it  would  know  to  go 
here  (points  to  iocition  eA 
in  the  'play  area')  and  if 
you  put  a  house  up  there 
(points  to  the  'program 
area') ,  it  would  know  that 
the  house  should  come 
t  here. 

We  can  try   it.    Try  the 

•run'.     You   told   it  to 

remember,  and  then  you  say 
OK,  do  it  . 

(Linda  touches  'drop'.) 

OK,  want  to  try  it  now? 

(Linda  touches  'run*  --  the 
program  puts  a  house  into 
the  'play  area '. ) 


For  the  first  time 
Linda  sees  that 
something  other  than 
a  'store1  picture 
and  'drop1  can  be 
put  into  a   program. 


Here  she  demon- 
strates that  she  un- 
derstands the  con- 
cept of  ' program 
pointer  '. 

Both  she  and  Tim my 
often  thought  that 
the  computer  would 
"know"  to  do 
something. 


This  shows  that  she 
is  thinking  about 
the  commands  and 
realizes  that  tne 
computer  would  not 
"know"  to  'drop'  the 
nouse,  that  she  must 
tell  it  to  do  so. 
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This'll  put  a  house  there 
evf»ry  time  we  '  lo'  it.  Tne 
next  time  we  'do*  it, 
wh.it  '  1 J     ha  ppen? 

Tt  won't  work  unless  you 
erase  the  house. 

Can  you  erase  ths  house? 

Py  the  broom? 

(Linda  touches  'broom'.) 
wood.  Now  let'r;  run  *tina' 
again,  (Linda  touches 
'run'.)  S  o  a  pr  og  ra  m  is  an 
easy  way  for  us  to  do  some- 
thing once  and  save  it. 

(tianna  asks  how  Linda 
things  a  program  is  put 
away  and  saved,  Linda 
points  to  the  'wrap1  edit- 
ing command.) 

Yoa,  wrap  it  up  and  nut  it 
away,  push  it.  {Linda 
tourihes  'wrap').  Where  did 
it.  put  the  program? 

Here  (points  to  'tina'  in 
the  'program  store'). 


Linda  seems  to  un- 
derstand the  idea 
that  a  program 
"remembers"  the  com- 
mands and  can 
wKecute  them  at  a 
liter  time. 


She  did  not  have  any 
trouble  saving  or 
•wrapping*  programs. 
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3.2.4  Linda  --  Session  4: 

Linda  Writes  a  Program  using  'iovp'. 

Tn  this  session  Linda  wrote  and  then  analyzed  a 
program  which  'joins'  a  boy  with  a  bike  and  moves  them 
across  the  'play  area*.  Linda  had  written  programs  for 
one  hour  in  session  2  and  one  hauc  20  minutes  in  session 
3. 


h    H    S  C  P  I  P 


20    minutes    into    ses^iinn_'j. 

(Linda  had  written  programs  to 
place  'store'  pictures  into 
the     'play    area • - ) 

U :  Can  T  ask  yo i  to  w^ite  a 
program  that'll  nut  i  boy 
on  a  hike  in  the  low<^c  left 
hand  corner  and  then  move 
it    all    the    way     icross? 

(Linda  touches  'write'  and 
calls  her  pro j ram  'sue*. 
She  then  touches  a A,  boy, 
'drop',  bike,  'join*,  then 
pa  uses, ) 


H :  How 
want 
way    across. 


do      you      move      it?         I 
you    to    move    it    all    the 


-M- 


(Linda  touches  aA,  'move 
right',  bA ,  'move  right', 
cA,  'move  right',  dA,  'move 
right',  eA,  '  !;-.ove  Light', 
At  this  point  the  program 
is  filled,  Linda  touches 
•run  '.  ) 


Linda  understands 
that  an  arrow 
' moves'  a  picture, 
nut  ls  unclear  about 
the  fact  t  ha t  it 
also  moves  the  cur- 
rent address  of  the 
•active  square' . 
'!er  program  does 
work,  however- 


6ii 


H: 


Wor  ks 
O xoc  utes 
a  bicycl 
aiwl  rao 
pict ures 
of  the 
f  A ,  not 
across.  ) 
N  o  w      u  h  a 

t  he      pro 
poi  n  ts 
command 
a  A,         ho 
•  join' , 

Of       'Sets 

and    asks 

the    com  in 


!  (Th 

and    pu 

e    onto    p 

ves      the 
across 
screen 

<  ]  u  i  t  e   a  1 
OK,     p 

t      does 

points    t 

■jram. 

to      each 
in      the 

aA    and    t 
1    and     'in 
L  inda 
ands  :) 


e         proyram 

ts    a    boy    on 

osition      a A 

compos  it  e 

t h  o      bottom 

to    position 

1       the       way 

retty    good. 

t  hi^         do? 

o    the    aA    in 

She         then 

success  iv  e 

progra  m: 

op • ,       bike, 

iie    sequence 

ove    rights' 

to      explain 


L: 


It  puts  the  active  square 
(points  to  lower  left  cor- 
ner,   position    aA)  . 


Manna  is  trying  to 
have  Linda  analyze 
her  program  step  by 
step. 


The  sequence  of  com- 
mands neeied  to  put 
pictures  into  the 
'play  area '  seems 
clear  to  Linda,  even 
when  they  occur  in  a 
program- 


It        (the       bov)        joes    in    the 
'finger      box'.         Then      this 
(points         to         the       '.irop') 
makes    it    come    here       (points 
to    position    a  A)  . 


She  understands  what 
the  commands  do  and 
is  able  to  analyze  a 
program. 


Tnat     (bike)    goe.s 
(•finger    box ' ) . 


in  the  bo x 


It   (the   'join')   puts 
(the  bike)  on  the  boy. 


it 


H;  OK,  why  does  it  put  it  on 
the  boy?  How  does  it  know 
to  put  it  on  the  boy  and 
not  iiu  here?  (Points  to  a 
position  in  the  upper  por- 
tion   of    the    'play    area'.) 


Because    those*    are 
commands, 

0K#  qood,  T'his  means 
'join1,  it  means  join  what 
to  what? 
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L:  The  hoy  with  the  bicycle 
because  he's  in  the  'active 
square  '. 

K:  '5ooi,  right.  (T.inda  con- 
tiauis      with   her   analysis,) 

L:  That  (points  to  position 
aA)  moves  the  active  square 
to    there. 

H:  Shore        was      the      active 

square    before    this? 

L:  It  was  there  (points  to 
aA)  . 

tl:  Piqht,  so  this  isn't  real- 
ly necessary-  Now  what 
does    this    clo?  (Joints      to 

the    first    'move    right'.) 

L:  Tt  moves  it  over  to  that 
(DA), 

H:       What    does    it    move    now? 

L:  It  moves  the  boy  and  the 
bicycle, 

H:  And?  Does  it  move  the 
'active    square',    too? 

L:       Yea. 

U:  So  now  what  does  this  do? 
(Points  to  bA,  the  next 
command  in  Linda's 
program. ) 


Lt  seems  clear  t hat- 
Linda  also  under- 
stands the  function 
of  the  'join' 
command. 


Because  the  children 
do  not  see  the 
•active  square'  move 
while  they  are  writ- 
ing a  program,  they 
often  put  in  extra 
•set*  commands;  to 
be  sure  that  the 
'active  square'  will 
be  where  they  want 
it.  This,  again  is 
because  it  is  diffi- 
cult to  translate 
the  commands  in  the 
program  to  corre- 
sponding actions 
when  the  program  is 
executing. 
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L:  That  moves  ( he  sit a tcs)  — 
that  movos  —  (paujes)  — 
that's  where  the  active  -- 
that  doesn't  move  it  but  it 
was    there, 

(Linda  erases  the  program 
and         rewrites         it;  aA, 

'hoy1,  'drop'  ^A,  bike, 
'  join',  bA,  anH  8  'moves 
ri  jht'.) 

H:  '-.'hat  does  this  uo  (points 
to    bA    in    the    new    program. 


Ll 
ve 
be 
st 
sh 
sq 
ia 
wh 
an 
Sh 
'  m 
ac 
we 

CO 


[1  da 

ry 

g  iii  n 

and 

ip   o 

uare 

ngua 

ich 

d      i 

e 

ove' 

t  ive 

11 

nten 


mak 

her 

ing 

th 

f    t 
i 

ge 

ac 
ts 
re  a 
a 


es 
e! 


a    di 
Sh 


to      un 
e    relat 

he      •  ac 
with 

COM 

t      upon 
conte 
lizes 
ffects 
square 
as 


sco- 
e  is 
der- 
ion- 
ti  ve 

the 

a  nds 

it 

nts- 

tnat 

the 
as 

the 


tS. 


It       doesn't.       move    the    boy 
there,  just  the  box 

(•active    square* }  . 


-H- 


(Lin 

da       rewr 

part 

of    hec 

'sue 

•    now    co 

boy. 

•  d  r  o  p ' 

'join',      a  A , 

right'    at    wh 

was 

no      more 

prog 

r  a  hi  .         T 

'  i  un 

• ,    the    p 

a  n  'i 

puts    a    b 

at.    p o s i t i o n 

to    i 

A,    one    p 

the 

right    ed 

area 

'-) 

ites   the   last 

pre  j  ram  so  that 
nsist s  of:  a A, 
,    aA ,    bike, 

and  3  ' mov es 
ich  ;  oint  there 

room  in  the 
lien  s;ip  touches 
rogram  executes 
oy  on  a  bicycle 
a  A  and  moves  it 
osition  before 
ge  o  r  the  'play 


with  a  little  hint 
Li  nda  discovers  her 
own  error. 

-I- 
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3.?.l3  Linda  --  Session  6: 

Linda  Learns  about  Subroutines  ml  user,  Loops. 

Here  Lin  la  wrote  a  program  which  called  subroutines 
and  incorporate!  'loops*.  Loops  were  introduced  in 
session  r>  where  Linda  worked  with  the  concept  for  one 
hour.  Before  session  6  she  had  used  programs  for  a  total 
of  four  hours,  40  minutes. 


P  T 


Five  minutes  into  session  6. 


(Han  in 
pr  o  gr  a  ,t 
city, 
w  it  h    an 
of        pu 
trees . 
g  ram 
' drop' , 
•drop'  , 
•  drop' , 
•drop'  ; 
gram    i  s 
•run'  , 
into      t 
sh  o  r  t    o 


suggested    L 

to      creat 

She    sugges 

«r-3sier      pr 
tting      down 
L  in  la    sta  r 
' tree  '  : 
bG, 

1G, 
fG, 
at    this 
filled. 
a    row    of 
he       'play 
f    a    full    ro 


'  d 

t 

•d 

DO 

"  L 
7 


i  rid  a 
e      a 
tod 
ohle 

a 
ts    t 

AG, 

rop  • 
J  rop 
rop' 
int 
i  nda 
tree 
i  rea 
w.) 


wl  it  e    a 

whole 

starting 

r,,       that 
row      of 
he       p ro- 
te ee, 

CG, 
eG, 

/    g  g  , 

the  p  r  o  - 

touches 

s  IS  put 

i   __   3 


Linda   shows  confi- 
dence   in    writing 

pr ogra ms, 


tl :  Eh,  pretty  good.  Would 
there  be  some  way  }f  doing 
the    same    thing    but       patting 

it.  in  a  'loop'?   'lore's  aG, 
where  •  s  bG  ? 


iiinna  begins  to 
introduce  the  'move 
active'  command. 


L:   One  over. 

H:  Is  there  some  way  of  put- 
ting the  active  sjuare  one 
over  without  touching? 


-H- 
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<Ll 

d  C  t 

pro 

'  di 

'  I!1  O 

•  on 

•i  u 

mov 

are 

aro 

ii  j a  point s  to  •  move 
jve'  and  rewrites  her 
ji  im  'tree':  a 3,  tree, 
op',  bG,  'begin  Loop', 
V  active  right',  'out', 
d         loop'  i  nd       touches 

U  '.  The  'active  square* 
es  across  the  'play 
a  ' ,  but  only  one  tree  is 
pood.) 


Here  Linda  is  get- 
ting the  idea.  She 
Knows  what  '  move 
ict i ve '  means  and 
what  a  ' Loop*  does; 
she  just  has  trouble 
putting  them 

together. 

-fi- 


ll: Is  that  what  you  wanted  it 
to  do?  There's  one  thing 
it's  not  doing. 

L:   Putting  the  tree  down. 

(Linda  erases  tne  loop  part 
of  the  program  so  that  now 
'tree1  contains:  aG,  tree, 
•drop1,  bG,  'begin  loop', 
tree,  'drop',  'move   ictive 


•4  • 


i  lyli 

Thi 
out, 
see 
I'  11 
go  in 
each 
like 
asks 
will 


out 


end    loop ' . ) 


;    time    before    we    try    it 

let's  look  at  it  and 
what      it's      gonna       do. 

be  the  little  hand 
I    down     (Manna    points    to 

subsequent  command, 
fl    program    pointer,    and 

Linda  whit  each  one 
do.       aG    is      the      first 


She  is  determining 
the  correctness  (or 
incorrectness)  of 

her  program  by  'run- 
ning' it  and  watch- 
ing   the    results. 


co  hi  m  a  n  1 .       ) 


L:  'Active      square'     is    gonna 

go    there    (points      to      posi- 
tion   aG)  . 

(tree  is  the  next  command) 
Put  the  tree  in  here  (fin- 
ger   box)  . 


Lind^i  appears  to  be 
able  to  debug  and 
correct  a  program. 
She  is  showing  con- 
tidenco  in  writing 
md  analyzing 

progra  ins. 


{ ' d r o p ' )       Put      r  he      t ree    i n 
the    'ictive   squire'. 


7J 


(b())  Puts    the    Motive 

square'  over  here  (points 
t  o  hG)  . 

(Hanna  skips  'begin  loop* 
and  points  to  tree)  Put  the 
tree  in  the  'finger  box'. 


Linda   is 
associate 
wi  th 
act  ions 
execut  ion 
program. 


able    to 

commands 

subsequent 

of  the 

of         the 


H: 


(•drop')  Tree        goes        in 

'active    square'. 

C^ovf  active  right')  Moves 
the    'active    square'     over. 

(  'out')     Nothm  j. 

mhori  it  (the  'hind')  goes 
down  to  here  (points  to 
'end    loop*),    and    then    what? 

The  hand  {•program  point- 
er')    moves    up. 

(Ilanna  nioves  hoc  hand  up 
and  points  to  ' bojin  loop' 
and  bacK  down  one  to  the 
com a and    tree.) 

Put  the  tree  in  the  'fin- 
ger   box'. 

Hram,    is    that    what    you    want 

it  to  do? 


Linda  seems  to  un- 
derstand addressing 
and  its  relationship 
to  the  'active 
square' . 

-H- 


Linda  can  analyize  a 
program  to  figure 
out  what  she  had 
done  wrong,  but 
needs  help  with 
figuring  each  com- 
mand out  step  by 
step. 


(o 


What  do  you  want  it  to  do? 
Where  do  we  want  to  put  the 
free? 


Here  she  didn't  have 
to  see  the  program 
fail  to  realize  that 
it    would    fail. 


L :      In    the    'active   square*. 

4 :     So   what   should   we   do 
dif f eren tly? 
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(Linda  changes  the  program 
•tree'  to:  aG,  tree,  bG, 
'be j in  loop' ,  ' i rop' ,  'move 
active  right',  'out*,  'end 
loop  '.  ) 


5a e  does  not  hesi- 
tate when  fixing  her 
program. 


if:       Do    you    want    to    try    it    now? 

(Linda  touches  'run',  the 
program  puts  a  r:n»  of  trees 
into    the    'play    ire a*.) 


Yea!  That's  really  great! 
What  would  you  hive  to  do 
to  put  down  a  low  of 
houses? 


Th is  is         Linda ' s 

first         introduction 
to    calling    programs. 


L:  Sa.no  thing.  Except  where 
you  have*  a  tree  there*  d  he 
a    h  o  u  s  e . 

H:  The  ilea  was  to  put  a 
whole  city  do^i;  with  one 
program.  Look;  lLke  we 
need  nior°  than  one,  doesn't 
it? 


(lianna    shows 

Lin 

d<i 

a    'book.' 

-pre 

def ined- 

pro 

jra.T    called 

'line':              ■ 

beg 

in 

loop' , 

•dro 

p ' ,             '  move 

act  ive 

rig  a 

t • ,       'out 

1  en 

l    loop'. 

She 

points    out    t 

n  at 

it       is 

exac 

tly       the 

si 

me 

as      the 

last 

half    of 

Linda 

•  s      p  r  o  - 

graii 

a  n  1    t  ha  t 

tb 

e    ] 

oop    por- 

t  i  on 

or    the 

pro 

gra 

n    ' tree' 

can 

bo    replaced 

by 

•  line'. 

Lini 

a      starts 

a 

new 

p  l  o  g  r  a  m 

•  how 

'    and    writes 

t 

he      com- 

hi  and 

s  :        a  F , 

ho 

use 

,     'drop' 

bF, 

•  line'  .) 
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II:       Mow    what    do    yoii    thin*,    will 
happen    if    you    run    it? 

L:         The      program    will    tun,     it 
will    put    the    houses    here. 

(Linda  touches  'run',  'how' 


put.;  i  house 


on 


the   left 


side  of  the  'play  acen'  and 
then  'line'  is  lisplayed  in 
the  •  program  space*, 
'line'  executes  and  puts 
down  a  row  of  houses*) 


-fi- 


ne re  Linda  is  just 
following  direc- 
tions, does  not  seem 
to  understand  fully 
what  she  is  doing- 


Being  able  to  put  another 
program  in  your  program  is 
a  shortcut.  You  can  use 
•line1  in  a  lot  of  places. 
Can  you  Take  a  street  under 
the  houses  ? 


(Linda  adds  aF,  horizontal 
line  (from  the  'store'), 
'drop',  bE,  'begin  loop', 
'drop',  '  mov<'  active 
right'  ,  'out',  *  p  n  d  loop'.) 

Good,  want  to  try  it  now? 
(Linda  touches  'run'  and 
the  program  puts  a  line 
under  the  houses.)  A.gain, 
this  is  the  same  as  'line1 
(points  to  the  'loop'  por- 
tion of  'how'). 

So  we  can  -just  replace  it. 
(She  replaces  the  'loop'  in 
her  program  with  'line'.) 

See  what  a  shortcut  it  is? 
Do  you  want  to  add 
something? 


This  shows  that  she 
isn't  comfortable 
with  calling  pro- 
grams since  she 
writes  out  the  loop 
(with  which  she  does 
feel  confident) 
instead  of  just 
calling  ' line' . 


-H- 


Here  Linda  seems  to 
understand  the  con- 
cept of  calling  pro- 
grams, she  just 
needed  help  in 
thinking  about  when 
she    can    use    it. 
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(Linda  adds  to  tno  program 
and  'how'  becomes:  aF, 
house,  'drop',  bF ,  •line1, 
aE,  horizontal  line, 
'  drop' ,  bE,  ' lino' ,  aDf 
dog  ,  '  drop  '.  ) 


Linda  writes  a  pro- 
gram by  herself. 
She  needs  very  few 
hints. 


OK,  do  'tree'  and  do  'how' 
and  do  a  couple  of  other 
things,  too.  Want  to  try 
it? 


(Linda 

touches    • wra 

S'. 

the  n 

' wri  to 

'    -ind    Cdlls 

thu 

new 

pr  o  gra  m      'name'. 

S  ho 

then 

touche 

s           the            c 

o  in  ili 

auds : 

*  how ' , 

•  tree* ,       a 

T, 

sun. 

'drop • 

,      a  A,       c-jl. 

'  d 

rop'  , 

'  move 

r  i  gh  t ' ,    '  t»  o v e 

ri 

ghf, 

c(I,        w 

itch,       'drop' 

/ 

•  move 

right  ' 

,            'move 

ri 

ghf. 

Linda 

touches       'r 

u  n' 

and 

' name' 

ca lis       'how 

i 

which 

puts 

a    house    on    th 

■  i    s 

creen 

and      c 

•ills         'line' 

which 

extend 

s      the    house 

to 

a   row 

of      houses.          ' tree 

1 

puts 

down 

a    trpe    and    al 

SO 

calls 

•  line' 

to      get      a 

row      of 

trees. 

A      sun, 

car 

and 

witch 

are    also   added.) 

(See  section 
for     the 
La  you t    of 

programs. ) 


2.  1.6.  2 
screen 

t  he 
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1.1  Observations  Derived  from  the  Tests. 
1..1.1  How  the  Concepts  were  Analyzed. 

From  the  tests  we  we ra  able  to  make  observations  about 
which  programming  concepts  were  easy  and  which  were 
difficult  for  the  children.  In  the  rollowing,  each 
programming  concept  is  listed  with  an  assertion  about  its 
difficutly.  heterences  to  the  tests  <ire  made  to  indicate 
the  basis  for  our  comments.  Where  applicable,  statis- 
tics, such  as  length  of  time  required  to  learn  the 
concept,  have  been  extracted  from  the  protocols.  The 
transcripts  in  section  3.2  are  referenced  or  short 
transcripts  are  included  where  pertinent. 
3.3.2  System  Modes. 

3.3.2.1  Immediate  Execution. 

The  immediate  execution  mode  rfas  introduced  first 
because  it  was  a  way  of  aguamting  the  children  with 
the  system  and  language  commands.  The  children  were 
taught  how  to  jse  the  commands.  They  were  not  intro- 
duced to  the  idea  of  using  them  in  a  specific  "mode". 
They  found  it  very  easy  to  work  witii  PAL  in  this  mode 
since  the  results  were  visible  • immediately ' .  All 
children  we  worked  with  were  able  to  use  the  language 
commands  with  confidence  within  the  first  hour  of 
exposure  to  nAL.   They  were  able  to  draw  pictures  using 
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the  command  sequence:  'touch  store',  'pick  up',  'set 
play  area',  'diop1.  (Version  2  of  PAL  no  longer 
requires  th<?  'pick  up',  sec  Appendix  A  for  and  explana- 
tion of  the  differences  between  versions  1  and  2.)  The 
children  wei  o  ^ilso  able  to  move  parts  of  thoir  scenes 
using  the  'move'  commands  as  well  ao  use  'join'  and 
•take  away' . 

In  session  1  Timmy  drew  a  picture  composed  of  a 
tree,  house,  moon,  balloons,  a  girl  on  a  bike  holding 
an  umbrella  and  a  boy  on  a  hike  also  holding  an 
umbrella.  Me  received  no  help  with  the  picture, 
although  he  did  occasionally  touch  'drop'  l-etore  he  had 
•picked  up'  a  'store'  picture  (the  'active  square1 
would  still  be  acound  the  'store1  picture),  but  always 
noticed  his  mistake  and  corrected  it  by  himself. 

At  the  end  of  session  one  (alter  one  hour  of 
instruction),  T'immy  pointed  to  each  comiani  in  turn  and 
explained  its  meaning: 

('pick  up')  "makes  things  come  here"  (touches  'fin- 
ger box')  ; 

('drop')  "makes  things  go  in  here"  (touches  'active 
square'  in  the  'play  area ')  ; 

('move  right')  "makes  things  go  that  way"  (points  to 
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the    r  ight) , 

Linda's    picture    after    one    hour    of    exposure    to    PAL; 


aaJLUtU-S    T 


&  J^ 


$ 


feat 


& 


-00- 


/ 

\ 

5   5 


♦GD* 


/'A  -1V 


■»(D« 
■00- 


n 


d 


out 


hanna 


w 


dnv  rte 


run    str 


ooy 


tre«  oarr 


N. 


abcdefghij 
71. 


§y 


ffl 


flsf 


how 


* * 


namal  l n« 


She  needed  no  help  with  her  picture  and  made  fewer 
errors  since,  in  version  2,  one  square  is  always 
'active1  in  the  'play  area'. 

At  the  end  of  session  one  Linda  also  described  the 
meaning  of  the  commands: 

L:   This  on<,  (points  to  'drop')  means  to  put   something 
in  there  (points  to  the  'active  square'). 
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H:       In    where,    what's    this? 
L:       In    the    'active   square'. 

And      this     (touches    the    'move'    command    expanding    it 
to    tour    separate       'moves')       moves      them      up       (touches 

•  move    up'); 

and    this    ('  join')     to    put    them    together; 

and    this     ('take    away')     to    take    them   apart; 

and      Mis       ('erase')       means    to    erase    what's    in    the 

•  ic  ti  ve    sq uare ' ; 

and  this  one  ('move  active')  means  to  move  the 
square  without  anything  in  it. 
The  cohcopr.  of  'immediate  execution'  was  much  more 
difficult  when  viewed  as  a  separate  mode.  When  it  was 
necessary  to  touch  a  separate  square  to  get  into  the 
'immediate  execution*  mode,  the  children  were  often 
confused.  Changing  modes  is  a  mor^  abstract  concept; 
nothing  really  happens  on  the  screen,  only  the  'state' 
of  the  system  is  changed. 

Timmy  was  introduced  to  ' immediate  execution'  as  i 
separate  mode  in  session  4  (for  10  minutes).  Timmy 
wrote  a  program,  then  sa>m;i  it.  A  message  appeared 
requesting  i  press  of  the  -NEXT-  key  if  *  new  program 
is  to  be  wiitten.  (In  version  ?  no  message  appears, 
the  child  has  to  touch  'write'  to  start  a  new  program.) 
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J:       Do   you    want    to    make    a    program   or   do    you    just... 

T:       No,    I    don't    want    to    make    a    program. 

J:       OK,    then    you    have   to    push    this    square     (John    touches 

'immediate      execution',       later      called      'do         mode'). 

That's      the    opposite   of    this    one    (points    to    'write*); 

that    means    you    don't    want    to    write    a    program. 
At    other    times   John    mainly    helped    Tirrimy      invoke      the 
modes      when       it      was    required.        (See    section    3.2.2,    the 
partial    transcript    of   session    14.) 

Linda  was  first  introduced  to  'do  mode'  as  a  system 
command  for  35  minutes  in  session  2  (see  section 
3.2.4).  To  get  Linda  used  to  the  'immediate  execution1 
mode  at  the  end  of  session  2,  Hanna  md  Linda  executed 
the  programs  Linda  had  written  earlier  that  session. 
Five  minutes  into  the  session  3  Hanna  asked  Linda  to 
write  a  program  which  puts  a  garage  around  a  car. 
Linda  had  used  'join'  in  session  1  (in  the  immediate 
execution  mode)  to  put  vertical  and  horizontal  lines 
around  a  ca r  to  represent  a  garage.  Because  Linda  had 
just  written  a  program,  she  was  still  in  the  'write' 
mode.  For       about       15      seconds      she      contemplated       the 

problem,  touched  'immediate  execution',  then  'write' 
and  again  'immediate  execution'.  After  drawing  a 
garage    in   the    'immediate    execution'    mode,    she    again 
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went  into  'write'  mode.  The  above  indicates  that,  by 
session  3,  Linda  was  very  confident  in  invoking  and 
using  the  'immediate  execution'  mode  and  used  it  as  a 
reminder  of  which  sequence  oi  commands  to  use  for  a 
particular  problem. 
3.1.2.2  Program  Writing. 

The  conceit  that  a  program  is  a  list  of  exactly  the 
same  commands  one  used  in  the  'immediate  execution' 
mode  seemed  to  be  the  most  difficult  concept  for  the 
children-  The  idea  of  a  program  is  abstract;  the 
children  don't  see  any  results  until  it  is  executed,  at 
which  timo  they  find  it  difficult  to  see  the  relation- 
ship between  the  command  they  had  touched  long  ago  and 
the  events  happening  on  the  screen. 

On  the  other  hand,  the  concept  of  touching  'write1 
to  go  intc  'write1  mode  to  start  a  program  was  easily 
and  guickly  jrasped.  The  children  understood  how  to 
start  a  program,  but  not  wuat  to  do  nice  they  were  past 
naming  It. 

Timmy,  for  example,  touched  'write'  very  confidently 
and  also  named  the  program,  then  usually  asked:  "Now 
what  do  I  do?"  (See  section  3.2.1,  the  beginning  of 
session  5.) 

In  session  '4  John  asked  Tim  to  write  a  program  to 
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make  a  balloon  90  all  the  way  to  the  top  of  the  'play 
area'  and  come  half  way  back  down.  Tim  my  touched: 
•pick  up',  dA ,  'drop',  balloons,  followed  by  several 
•moves  up'  commands.  This  ssems  to  indicate  that,  by 
session  4,  he  had  an  idea  thdt  a  program  is  a  list  of 
commands  to  be  saved,  but  was  not  sure  of  the  sequence 
of  commands  nor  was  he  able  to  analyze  what  the 
commands  woull  do  (without  seeing  them  execute).  Tim 
could  accomplish  the  task  veiy  easily  in  the  'immediate 
execution'  mode;  thus  the  difficulty  most  likely  lies 
in  translating  the  concrete  commands  as  learned  in  the 
•immediate  execution'  mode  to  abstract  commands  in  a 
program. 

By  session  14  Timmy  was  confident  with  writing 
programs.  Svea  though  he  still  asked:  "Now  what  do  I 
do?'1,  he  didn't  wait  far  an  answer  (see  section  3.2.2). 

The  time  Timmy  spent  learning  to  program: 


Session   2   --   50   minutes.   John  helped  Tim  write  one 

program. 
Session  3  --  40  minutes.   John  reintroduced  programming 

and  helped  Tim  write  two  programs. 
Session  4  --  50  minutes.   Timmy  still  needed  help   with 

writing  program,  but  less  than  previously. 
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Session   5   —  33  minutes.   T i in  gained  a  clearer  under- 
standing of  programming  and  wrote,  on   his   own,   the 
program   'city1   which   consists  o£   fA   and   'move' 
commands  (see  section  3.2.1). 
Session  6  —  23    minutes.   Tim  had   more   confidence   in 

writing  programs  and  wrote  one  containing  a  'loop'. 
Session  7  G  8  --  f>0  minutes.   Timmy  practiced  using  PAL 
on   his   own   (Hanna   was   there  just  to  answer  ques- 
tions) .   He  chose  to  write  programs,  not  just  to  stay 
in  the  'immediate  execution'  mode.    On   his   own   he 
wrote   the   programs   'copy'  which  put  a  car  into  the 
•play  area'  and  moved  it  to  the  right  using  a   'loop' 
(containing   an   'exit')   and  'zoom'  which  also  put  a 
car  into  the  'play  area'   and   used   a   'loop'   (with 
'exit')  to  move  it  up. 
Linda   was   ficst   introduced   to  program  writing  15 
minutes  into  session   2   (sea   section   3.2.3   for   the 
transcription).    Five   minutes   later  Linda  understood 
how  to  begin  writing  programs  md  how  to  name  them. 

der  first  programs  consisted  of  a  series  of  'store' 
pictures  which,  upon  execution  of  the  program,  would 
appear  in  the  'tinger  box'.  The  translation  of  famil- 
iar 'immediate  execution'  commands  to  commands  which  do 
nothing  but  appear  in  a  program  was  also  difficult  for 
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her.    She  too  had  trouble  seeing  whit  the  command  in  a 
program  would  do  when  a  program  was  •run*. 

Linda  gradually  learned  to  use  more  and  more  com- 
mands in  her  programs  and,  by  the  end  of  session  2 
(after  one  hour  of  programming  experience),  was  confi- 
dent with  writing  programs  which  put  pictures  into  the 
'play  area'.  Mot  until  much  later  was  she  able  to 
extrapolate  and  realize  that  all  commands  which  can  be 
used  in  the  ' immediate  execution'  mode  can  also  be  put 
into  a  program.  At  the  start  of  session  3  Linda 
explained  what  a  program  is: 
H:   What  is  a  program? 

L:  A  program  is  something  that  the  computer  can 
remember  after  you  drop  something. 
In  session  3  [{anna  aslced  Linda  to  write  a  program 
which  would  build  a  garage  for  a  car.  She  thought 
about  it,  went  into  'immediate  execution'  mode  twice  to 
remind  herself  which  sequence  of  commands  is  needed- 
After  10  minutes  Linda  wrote  the  program  'cat':  aH, 
car,  'drop',  aH,  vertical  line,  'drop',  aH,  horizontal 
line,  'drop',  aH,  slanted  line,  'drop1.  Tn  her  program 
Linda  used  only  commands  which  she  had  previously  used 
in  a  program.  She  then  touched  'run',  but  before  the 
fifth  command  was  executed  (tha  program  had  not  yet 
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failed),  Linda  said:  "I  don't  think  it's  cjonna  work." 
(The  program  would  have  failed  because  it  would  try  to 
•drop'  lines  on  top  of  the  car.)  Hanna  pressed  the 
-BACK-  key  to  stop  the  program  execution  and  asked  why. 
Linda  indicated  that  two  pictures  can't  be  'dropped* 
onto  the  same  square,  that  'join'  must  be  used.  She 
then  replaced  the  three  last  'drops'  in  her  program 
with  'joins'.  Execution  of  the  program  put  the  hori- 
zontal and  vertical  lines  in  the  correct  place,  only 
the  slanted  line  ended  up  on  top  of  the  car.  Linda 
discovered  her  error  and  immediately  changed  her  pro- 
gram so  that  the  final  execution  put  a  car  on  the 
screen  and  a  garage  with  one  slanted  wail  around  it. 
The  above  sequence  of  events  took  a  total  of  30 
m  inut es. 

Hanna  then  asked  Linda  to  use  'move'  in  a  program; 
Linda  required  15  minutes  to  write  such  a  program. 
This  appears  to  indicate  that  each  successive  command 
which  she  learned  to  use  in  a  program  took  less  time. 

The  time  Linda  spent  learning  to  program: 
Session  2  --  1  hour.   Linda  was  ablo  to   program   using 

'touch  store',  'set  play  ar^a'  and  'drop'- 
Session   3   --   1  hour,  20  minutes.   She  learned  to  use 

'join'  an"1  •  .Tiove '. 
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Session  U  --  1  hour,  5  minutes.  Linda  learned  about 
addressing  (recognizing  the  coordinates  in  the  'play 
area')  and  sequences  of  'moves'. 

Neither  Timmy  nor  Linda  had  difficulty  editing 
programs;  pressing  the  -ERASE-  key  to  erase  and  then 
replacing  the  last  command  in  the  program.  Both  were 
introduced  to  the  concept  in  session  3  ind  needed  no 
help  in  using  it  after  that. 

Recalling  a  stored  program  to  edit  it  was  more 
difficult.  (This  feature  was  not  available  in  version 
1.)  Linda  was  introduced  to  the  concept  briefly  (for 
five  minutes)  one  hour  into  session  3.  In  session  4 
she  was  again  told  how  to  edit  a  program  and  15  minutes 
later  recalled  and  edited  one  she  had  written  earlier. 
3.3.2.3  Program  Execution. 

After  having  written  a  program,  the  children  found 
it  very  easy  to  touch  'run'  to  execute  the  program. 
See  section  3.2.3  for  an  analysis  of  Linda  learning  to 
•run'  her  program.  Timmy  was  helped  the  first  few 
times  in  which  he  wanted  to  execute  i  program.  Section 
3.2.1  shows  that  he  had  no  difficulty  with  that  concept 
by  session  5. 

Executing  a  program  that  had  been  stored  was  not  as 
easy.   This  involved  two  steps,  first  touching  the 
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program  from  the  immediate  execution  mode,  then   touch- 
ing 'run1, 

At   the   start   of   session   3   Linda   looked  at  hec 
programs  in  the  'program  store': 
K:   Want  to  try  one?   How  do  you  make  the   computer   do 

the  program  that  you  wrote  last  time? 
L:    You   press   the  program  (touches  the  program  which 

then  appeared  in  the  'program  space'). 
H:   Now  how  do  you  make  it  do  it? 
L:   I  press  the  running  boy. 

One  hour  later,  Linda  was  in  the  'write'  mode  and 
wanted  to  execute  a  stored  program.  She  erased  all 
instructions  in  the  current  program  and  touched  the 
stored  program  'tina'.  Linda  was  surprised  when  'tina' 
became  the  first  instruction  in  her  current  program 
(she  had  not  been  introduced  to  subroutines).  Hanna 
explained  what  had  happened  and  that  programs  can  only 
be  recalled  from  the  'immediate  execution'  mode,  after 
that  Linda  was  able  to  execute  stored  programs  by 
herself.  rfhen  sue  did  make  the  above  mistake  (that 
happened  1  total  of  two  more  times),  she  immediately 
corrected  it  herself. 

Section  J. 2. 1  describes  how  Timmy  learned  to  execute 
stored  programs.   In  version  one  a  program  doesn't 
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appear  in  the  'program  space'  when  it  is  touched,  the 
"active  square  indicator"  (dotted  box)  appears  around 
the  program  name  in  the  'program  store1.  To  recall  it 
(and  at  the  same  time  execute  it),  'run*  mast  be 
touched-  This  mikes  the  concept  of  running  a  stored 
program  slightly  more  difficult  in  version  one-  Timmy 
is  confident  with  calling  programs  by  session  14  {see 
section  3.2.2)  and  even  causes  the  programs  to  act  on 
different  'active  squares'. 
3.  .1.2.4  Mode  Changing. 

Timmy  was  not  quite  clear  about  different  modes  in 
session  5  (see  section  3.2.  1)  .  He  wanted  to  cause 
something  to  happen  in  the  'play  arei  '  but  was  in  the 
'write'  mode;  he  wondered  why  touching  commands  did  not 
result  in  action.  Competence  with  changing  modes  was 
clearly  present  by  session  9.  (Section  3.2-2  illus- 
trates his  ability  with  the  concept  in  session  14-) 

Linda  showed  confidence  in  going  between  'write'  and 
'immediate  execution'  modes  by  session  3-  (Section 
3.3.2.2  contains  a  description  of  her  repeated  invoking 
of  the  'immediate  execution'  mode  to  remind  herself  of 
the  correct  sequence  of  commands  for  building  a 
garage.)  She  was  introduced  to  invoking  different 
'modes'  in  session  2  (see  section  3.2.4). 
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3.3.3    Memory    and    Data. 
3.3.3.1    Data    values. 

a.  Primitive  Constants- 

Children  were  able  to  use  the  primitive  constants 
(predefined  pictures  from  the  'store'  and  characters 
from  the  keyboard)  in  the  'immediate  execution"  mode 
after  10  to  20  minutes  of  exposute  to  r>AL.  (Linda 
required  15  minutes  and  Timmy  was  confident  after  20 
minutes.)  They  were  able  to  use  the  constants  to 
compose  pictures  in  the  'play  area'.  Linda's  first 
programming  attempt  consisted  solely  of  pictures  from 
the  'store',  indicating  thdt  the  concept  is  easy. 

b.  Composites. 

Combining  two  or  more  primitive  constants  to  a 
composite  was  slightly  more  difficult.  This  was  also 
taught  in  the  first  session;  Timmy  composed  pictures 
using  'join'  20  minutes  after  he  wss  introduced  to  it 
and  Linda  mastered  it  in  5  minutes.  Even  after  this, 
both  children  frequently  used  'droo'  when  'join'  was 
needed,  but  they  corrected  themselves  with  no  help 
after  seeing  'drop'  fail  when  the  'active  square'  was 
occupied. 

Using  composites  in  programs  also  proved  to  be 
more  difficult  than  using  'drop'.   In  session  11 
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Tim  my  wrote  i  program  to  draw  an  "XM.  (The  program 
consisted  of:  slanted  right  Line,  'pick  up',  cD, 
•drop',  slanted  left  line,  'pick  up' ,  cD,  •join'.) 
Linda,  in  h^r  first  attempt  to  write  a  program  which 
puts  a  car  into  a  garage,  used  'drop*  instead  of 
•join'.  She  needed  no  help  in  correctinj  her  error 
(see  section  3.3.2.2  for  a  description). 
3.3.3.2  Variables, 

The  idp>a  that  the  •  play  area'  consists  of  squares 
which  can  take  on  different  values  is  easily  mastered 
in  the  first  few  minutes  of  exposure  to  PAL.  As  was 
described  earlier,  it  takes  children  seven  and  older  no 
more  than  20  minutes  to  be  able  to  compose  complex 
pictures  in  the  'play  area*. 

Timmy  found  it  quite  difficult  to  write  a  program  to 
put  primitives  into  the  'play  area1.  Section  3.2.1 
(session  5)  shows  that  John  tried  to  guide  Timmy  to 
write  a  program  which  would  place  a  picture  into  the 
play  area,  but  had  to  jive  up  for  that  session.  Tim 
did  write  a  program  in  session  5,  but  one  using  only 
•move',  a  single-step  operation-  John  guided  Timmy  in 
writing  a  program  using  the  'pick  up*  and  'drop' 
sequence  in  session  2,  but  Tim  did  not  totally  under- 
stand what  he  did.   After  a  total  of  2  hours,  15 
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minutes   programming   time,   Timmy  did  succeed  in  using 
the  'pick  up',  'drop'  sequence  in   a   program   (session 

7). 

Cutting  pictures  into  the  'play  area'  is  much  easier 
in  version  2  since  the  'active  square'  is  always 
located  in  the  'play  area'-  Linda  did  not  find  it 
difficult  to  write  proyrams  which  put  pictures  into  the 
'play  area';  her  tirst  programs  did  that.  The  above 
seems  to  indicate  that  the  concept  of  variables  is  not 
difficult  if  the  implementation  makes  it  easy  to  use. 

The  children  had  to  initialize  variables  if  they 
wanted  to  execute  programs  which  put  pictures  into  the 
'play  area'  more  than  once.  If  the  'play  area'  is  not 
cleared  (swept  clean  with  the  'broom') t  the  second 
execution  of  a  program  will  result  in  the  'drop' 
commands  failing.  Timmy  frequently  noticed  (while  his 
program  executed  for  a  second  time)  that  he  should  have 
previously  cleared  th^  'play  area'.  He  did  understand 
the  concept  and  usually  stopped  the  proqran,  erased  the 
'play  area'  (in  version  one  the  -LAB-  key  had  to  be 
pressed  to  clear  the?  area),  and  reran  his  program. 
I. in  la  remenbeLed  to  clear  the  'play  area'  ibout  80%  of 
the  times  she  retried  a  program.  (In  version  2  the 
'broom'  is  pictured  on  the  screen  as  a  reminder.) 
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^he  concept  ot  variables  only  taking  on  'discrete' 
values  is  implicit  in  the  system.  Values  ot  variables 
consist  of  primitive  values  ('store1  pictures  or 
alphanumeric  characters  from  the  keyboard)  or  combina- 
tions of  them. 
3. 3. 3. 3  Stor lge. 

a.  Read  Only. 

Primitive  values  from  the  •store'  or  alphanumeric 
characters  from  the  keyboard  are  retrieved  from  'read 
only'  storage.  Paragraph  3.3.3.1  contains  an  analy- 
sis of  how  the  children  learned  to  use  these  primi- 
tive values.  Predefined  or  'book'  programs  are  also 
located  in  'read  only'  storage.  (Version  one  did  not 
contain  'book'  programs.)  Linda  was  introduced  to 
predefined  programs  in  session  6  (see  section  3.2.4). 
She  was  abls  to  invoke  a  predefined  program  from  her 
program  (with  little  help,  see  the  transcript)  10 
minutes  after  she  was  first  introduced  to  the 
concept- 

b.  Read/write. 

Procedures  written  by  children  are  stored  in 
'read/write'  memory.  Once  introduced  to  the  concept, 
the  children  found  storing  their  programs  very  easy. 
Neither  Tiramy  nor  Linda  forgot  how  to  'wrap'  a 
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program    (see    section   3.2-3,    Linda's      first      introduc- 
tion     to      'wrap1).         Writing    and   editing    programs    was 
more   difficult    and    is    analyzed    in   section    3.3.2.2. 
3.3. 3. 4    Addressing. 

The  concept  of  addressing  is  easy  to  grasp  and  was 
quickly  understood  by  the*  children.  In  PAL  locations 
are  referenced  simply  by  touching  them  -  addresses  are 
touch  locations.  Addressing  used  in  programs  will  be 
extensively  described  in  section  3.3.4.2. 
3.  3.  4    Programs. 

3.3.4.1    Sequence    of    Instructions. 

a.  Static  Sequence. 

The  concept  of  the  static  sequence  or  text  of  a 
program  is  implicitly  learned  while  learning  to  write 
a  program  (see  section  3.3.2.2)  . 

b.  Dynamic  Sequence. 

The  concept  of  the  dynamic  sequence  or  flow  of 
control  on  a  program  is  grasped  when  learning  to 
execute  programs  and  to  use  'loops*.  The  'loop'  and 
'out'  commands  cause  the  dynamic  sequence  to  differ 
from  the  static  sequence  of  a  program.  Thus  the 
concept  or  dynamic  sequence  must  be  understood  if 
•loops'  are  to  be  understood  (see  section  3. 3.4.2»2 
for  an  analysis  of  the  concept  of  'loops'). 
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c.  Program  Pointer. 

This  concept  was  learned  relatively  quickly  by  the 
children  since  they  actually  saw  the  'program  point- 
er* point  to  each  successive  command  as  it  was 
executed.  In  session  14  Timmy  seemed  to  understand 
the  concept  (see  section  3.2.2).  Linda  demonstrate! 
her  mastery  of  the  concept  in  session  two  (section 
3.2.3). 

d.  Syntax. 

PAL  has  a  very  simple  syntax;  the  only  restraint 
is  that  'loop'  parentheses  must  match  and  that  'out' 
must  be  inside  the  'loop'.  Neither  Timmy  nor  Linda 
ever  had  unmatched  parentheses;  they  see-ned  to  visua- 
lize a  'loop*  as  one  entity.  Timmy  did  reverse  the 
'loop'  parentheses  once  in  session  6.  Both  children 
placed  tne  'out'  outside  the  'loop'  .  (immediately 
following  the  'end  loop').  In  session  14  (section 
3.2.2)  Timmy  snowed  that,  even  though  he  put  the 
'out'  outside  the  'loop',  he  did  understand  its 
function;  he  simply  made  a  syntax  error.  Linda  also 
made  this  error  once  in  session  4  (section  3.2.4). 
Both  children  remembered  the  rule  once  the  error  was 
pointed  out. 
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3.3.4.2   Instructions. 

3.3.4.2.1    Primitive    Instructions. 
a.       Assignment    Statement. 

The  assignment  statement  is  "explicitly"  repre- 
sented by  the  PAL  'drop'  languige  command.  The 
•drop'  is  easy  to  use  in  a  program  (see  section 
3.2.3,  Linda's  first  programming  attempt).  It  took 
a  longer  time  for  Tiramy  to  use  'drop*  in  a  program 
because  it  was  more  cumbersome  in  version  one  (see 
Appendix    A)  . 

The  'touch  store'  command  assigns  a  'store1 
picture  to  the  'finger  box'.  This  proved  to  be  a 
very  easy  command,  the  first  language  command  Linda 
used    in    a    program. 

A  tiiird  explicit  assignment  statement  is  the 
•pick      up'      command.  Linda      used       'pick      up'    very 

seldom  since  it  was  not  very  useful  in  version  2  of 
PAL.  In  version  1  Tiuimy  had  to  use  'pick  up'  to 
get  'store'  pictures  into  the  'finger  box'.  He  did 
not  have  any  difficulty  understanding  the  command, 
he  only  confused  the  seguences  in  which  the  com- 
mands   had    to  appear. 

♦Erase'  (which  'erases'  the  contents  of  the 
'active   square')     also   proved    to    be    an    easy    concept. 
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In  Timmy 's  session  9  Hanna  wrote  a  program  designed 
to  put  one  row  of  a  cheese rboard  onto  the  'play 
area' .  The  program  contained  an  error  and  placed 
two  solid  squares  at  the  end  of  the  row-  Hanna 
then  asked  Timiny  if  he  could  rix  the  program. 
After  just  a  few  seconds  of  thought,  Timmy  added  an 
•erase1  command  to  the  end  of  the  program!  (The 
program  still  put  two  solid  squares  at  the  end  of 
the  row T  but  the  last  command  than  erased  the  final 
square.)  Linda  did  not  have  an  occasion  to  use 
'erase'  in  her  programs. 

The  assignment  statement  'join'  was  more  diffi- 
cult to  use  chan  'drop'.  The  children  must  be  very 
clear  about  what  'joins'  what  when  using  the 
command.  Timmy  wrote  a  program  to  compose  an  "X" 
from  slanted  right  and  slanted  left  lines  in 
session  11.  To  accomplish  his  task,  ae  had  to  use 
the  'pick   up'   and   'drop'   commands   as   well   as 


join 


Linda       used       'join'       in      session    3    to    put 


lines  around  a  car,  i.e.  to  build  a  garage.  She 
had  to  return  to  the  'immediate  execution*  mode 
several  times  to  help  remind  herself  how  to  use 
•  join'    and    how    to    translate    it    to    a    program. 

The    'take   away'    command    was   even    more    difficult 
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for  the  children  since  it  is  even  more  abstract 
than  'join'.  They  did  not  use  it  in  programs  and 
took  longer  to  master  it  in  the  'immediate  execu- 
tion' mode  than  all  other  commands  (with  the 
exception  of  'move  active'  which  was  not  useful  in 
the  'immediate  execution'  mode). 

The  'move'  statements  are  "implicit'*  assignment 
statement.  They  assign  null  to  the  present  'active 
square'  and  its  former  contents  to  the  new  'active 
square' . 

The  first  program  which  Timmy  wrote  on  his  own 
consisted  solely  of  'nove'  commands.  Linda  used 
'moves'  in  session  3  after  she  hid  written  programs 
which  'dropped'  pictures  onto  th3  'play  area'. 

b.  Unconditional  Transfer  of  Control. 

The  children  found  this  concept  relatively  easy, 
helped  by  the  tact  that  the  program  pointer  is 
visible  as  control  is  transferred.  Timmy  demon- 
strated his  familiarity  with  the  concept  in  session 
1U  (see  section  3.2.2)  and  Linda  in  session  6 
(section  3.2.5).  Section  3.3.4.2.2  contains  a 
further  description  of  the  concept  of  'loops'. 

c.  Conditional   Transfer   of   Control   (the   command 
'exit'  in  version  1  and  'out'  in  version  2). 
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This  is  not  an  easy  concept,  and  at  first  the 
children  used  an  'out*  with  a  'loop'  simply  because 
they  were  following  an  example.  In  session  14 
(section  3.2.2)  Timmy  explained  that  without  an 
•exit'  the  program  would  keep  failing  when  it 
reached  the  side  of  the  'play  area'.  Linda  demon- 
strated her  knowledge  of  the  'out'  command  in 
session  6  (section  3.2.5)  when  she  explained  why 
'out'  is  needed  in  the  'loop'  she  had  written. 

d.  Operation. 

The  operations  of  PAL:  'move',  'drop1,  'join', 
•take  away1  were  described  in  paragraph  (a.)  of 
this  section. 

e.  Addressi  ng. 

'Setting1  an  address  wis  very  easy  for  the 
children  since  they  only  had  to  touch  a  position  in 
the  'play  area'.  The  'active  square'  would  appear 
around  the  touched  position  as  the  "current  ad- 
dress". Both  children  learned  to  recognize 
addresses  by  their  coordinates  as  they  appear  in  a 
program.  In  the  following  Timmy  shows  that  he  is 
able  to  recognize  and  use  addresses  in  a  program 
(25  minutes  into  session  6)  : 
J:   I  have  one  puzzle,  ready? 


100 


T:         Yea.  (John      calls    a    previously    written    program 

which  consists  of  the  commands:  bC,  'move  up', 
'move  up',  'move  right';  and  displays  it  in  the 
•program    space'.) 

J;  OK,  here's  the  puzzle.  I  want  you  to  tell  me  if 
I  put  a  car  here  (puts  a  car  at  position  be  in  the 
'play  area')  and  if  I  put  one  here  (puts  a  car  at 
aA)     and    then    I    push     'run',    what    will    it    do? 

T:       I    don'  t    bow. 

J:   Well  you  have  to  look  at  the  list. 

T:  This  one  (points  to  the  cat  at  a\)  will  go  up 
one,  up  one,  and  then  over;  and  this  one  right  here 
(points  to  the  one  at  bC)  will  go  up  one,  up  one 
and  then  will  go  (points  to  tho  right). 

J:  How  do  you  know  that  they  will  both  go  like  that 
instead  of  just  one  of  them? 

T:   (pauses)  3ach  got  a  car. 

J:   Which  will  go  first? 

T:  (pauses  to  think)  No,  T  think...  T  think  this 
one  (points  to  bC). 

J:   Why? 

T:   Cause  it's  on  Cb. 

J:   Is  that  somewhere  else  Cb? 
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T:    No,  it's  right  up  there  (points  to  be,  the  first 
command  in  the  program),  be. 

When  Linda  was  writing  her  program  to  draw  a 
garage  around  a  car  in  session  3,  sae  positioned 
the  garage  by  watching  the  coordinates  in  the 
program  and  matching  them  with  commands  she  was 
writing. 

The  concept  of  addressing  was  much  more  diffi- 
cult when  the  addresses  were  change]  as  a  byproduct 
ot  the  execution  of  a  command  (specifically  in  the 
•move'  and  'move  active'  commands).  Timmy's  first 
solo  program  consisted  only  of  'move'  commands;  he 
did  net  explicity  think  about  addressing  different 
positions,  only  of  'movinj'  something  (see  section 
3.2.1,  session  5).  Timmy  found  it  much  more 
difficult  to  use  the  'move  active'  command  which 
only  moves  the  'active  square'  (the  current  ad- 
dress), a  much  more  abstract  concept.  The  'move 
active'  command  was  also  more  difficult  for  Linda 
(see  section  3.2.5,  session  6). 
3.3.4.2. 2  Composite  Instructions, 
a.   Procedures. 

In  session  5  John  wrote  a  demonstration  program 
which  called  another  procedure.   Hanna  also  wrote  a 
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program  which  calls  another  in  Timmy' s  session  9. 
Both  times  Timmy  did  not  follow  what  was  happening. 
He  did  not  seem  to  be  ready  or  interested  in  the 
concept,  so  it  was  not  pursued  till  Timmy  seemed 
more  confident  with  writing  programs.  Five  minutes 
into  session  13  Hanna  suggested  that  Timmy  write  a 
program  to  put  down  a  whole  row  of  solid  sguares. 
After  15  minutes,  Timmy  had  written  a  program  which 
put  down  four  sguares.  He  then  began  writing 
another  program  which  would  complete  the  row. 
Hanna  explained  that  he  could  add  the  first  program 
to  the  second  one  to  in<tke  the  whole  line  with  one 
program.  Timmy  seemed  to  like  th^  idea  of  one 
program  calling  another  and  wrote  one  consisting  of 
four  proyrams  which  ho  had  previously  written. 
When  he  touched  'run'  to  execute  the  new  composite 
program,  Hanna  asked:  "So  what's  going  to  happen?" 
Timmy  answered  "kapesh"  an1  indicated  an  explosion 
with  his  hands.  He  seemed  to  understand  that  a  lot 
would  occur  and  liked  the  ilea  of  putting  guite  a 
bit  together. 

Linda  was  introduced  to  calling  procedures  in 
session  6  (see  section  3.2.4).  By  that  time  she 
was  very  familiar  and  confident  with  the  concept  of 
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writing  programs.  She  was  first  (for  15  minutes) 
ta'ight  to  use  'book'  or  predefined  programs  and 
then  to  call  ones  she  had  written.  After  about  30 
minutes  she  called  subroutines  with  little  diffi- 
culty- At  the  beginning  of  session  7  Hanna  asked 
Linda  if  she  could  think  of  something  that  would  be 
difficult  to  program.  Linda  answered:  "Yes,  to 
write  letters."  She  then  wrote  a  program  to  place 
the  words:  "Hello  there"  onto  the  'play  area'.  To 
accomplish  this,  she  had  to  have  one  program  evoke 
another  since  one  program  can  only  contain  15 
commands,  too  few  to  write  both  words. 

b.   Loops. 

Timmy  was  introduced  to  'loops'  for  13  minutes 
in  session  6.  In  sessions  7  and  3  he  used  'loops' 
in  programs  for  a  total  of  40  minutes.  The 
following  excerpt  from  session  9  shows  that  Timmy 
seemed  to  understand  the  concept.  John  and  Timmy 
analyze  the  program  'copy'  which  Timmy  had  written 
in  session  3  ('copy1:  car,  'pick  up',  aA,  'drop', 
bB,  'drop',  'move  up*,  'move  up',  'move  down', 
'move  down',  'begin  loop',  'move  right',  'move 
right',  'exit',  'end  loop'). 

J:   What  does  this  one  do?   (Points  to  car) 


104 


T:   It  tells  you  what  to  'nick  up1. 

J:   Pick  up  a  car? 

T:   Yep. 

J:  What  does  this  one  do?  (points  to  the  'pick  up1 
command) 

T:      Picks    up   the    car. 

J:   Where  does  it  go  then? 

T:   To  aA. 

J  :   Then  wh:it? 

T:   It  'drops'  the  car. 

J :   Where  is  a  A? 

T:  This  one  here  (Timmy  points  to  aA  in  the  'play 
area').  It  goes  up,  up,  down,  down...  When  it 
comes  to  this  (points  to  'end  loop'),  it  goes  back 
up  to  its  brother  (points  to  'begin  loop*). 

c.   Nesting. 

In  session  6  (section  3.2.5)  Linda  wrote  a 
nested  procedure.  She  had  no  difficulty  with  the 
concept.  Nesting  of  'loops'  was  introduced  in 
session  8  when  Hanna  drew  a  maze  (see  Appendix  D) 
and  asked  Linda  to  write*  a  program  to  have  a  girl 
go  through  tne  maze  without  counting  (to  write  a 
procedure  for  general  mazes).  Linda  wrote  the 
program:   'begin  loop',  'move  right',  'out',  'end 
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loop';  an other  'loop'  with  an   'move   up'   and   one 
more   containing   a   'move   right'-    The   program 
brought  the  girl  one  square  short  of   all   the   way 
through   the   maze.   Hanna  then  suggested  repeating 
the  two  types  of   'loops'   over   and   over   (in   an 
attempt  to  have  Lin  la  use  ' nestei  loops'), 
H:   How  could  you  do  that? 
L:   By  running  it  again. 
H:    oh,   yp*#   you   can  run  it  again,  but  you  can  do 

other  things  to  make  it  go  over  and  over. 
L:   By  putting   it   in   a   'Loop'   (she   changes   the 
program   and   puts  a   'loop'   around   her  previous 
commands,  including  the  3  'loops*). 

This  shows  that  she   seemed   to   understand   the 
concept  of  'nested  loops'. 
1«  3.4.3    Determining    the    Correctness    of    Programs 
(Debugging)  . 

The  children  found  it  fairly  easy  to  determine  the 
correctness  of  PAL  programs  since  they  could  see  the 
state  of  the  system  at  all  times.  In  the  maze  example 
described  above,  Linda  wanted  the  girl  to  get  through 
the  maze.  Her  first  program  did  not  get  the  girl  all 
the  way  through  the  maze,  so  she  corrected  it  and  her 
second  program  did. 
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Analyzing  programs  step  by  stop  was  especially 
difficult  for  Timmy.  When  asked  what  he  thought  a 
program  would  do  before  he  tried  it,  he  would  invari- 
able answer:  "I  don't  know".  In  the  later  sessions  he 
was  able  to  analyze  programs  fairly  well,  although  he 
did  still  need  prompting.  Paragraph  (e. )  of  section 
3.  3.U.2.  1  (addressing)  illustrates  that  Timmy  was  able, 
by  session  6,  to  tell  what  a  simple  program  (be,  two 
'move  up',  'move  right')  will  do.  In  session  14 
(section  3.7.2)  Timmy  was  able  to  debug  a  program  which 
he  had  written. 

Linda  was  more  patient  and  was  able  to  analyze 
programs  by  sessions  U  (section  1.2. 4)  and  6  (section 
3.2.5).  Even  in  her  first  programming  attempt  (session 
7,  section  3.2.3)  ,  she  was  able>  to  do  some  limited 
debugging  when  prompted  to  jo  through  her  program 
instruction  by  instruction. 
3.4  Summary  and  Conclusions. 

3. '4.  1  Abstract  Concepts  are  Most  Difficult. 

The  most  dirficult  concepts  for  the  children  were  ones 
whose  results  were  not  seen  immediately.  In  the  'immedi- 
ate execution1  mode  the  only  language?  commands  which 
caused  any  difficulties  were  the  'move  active'  commands. 
They  represent  an  abstract  form  of  addressing  whose 
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results  depend  on  a  succeeding  operation.  Direct  ad- 
dressing  was  easy  ior  the  children  since  addressing  a 
square  is  just  a  matter  of  touching  the  desired  coordi- 
nate. Indirect  addressing  ('move'  and  'move  active')  was 
moire  difficult  as  the  children  oft^n  lost  track  of  where 
the  current  address  was  and  what  that  location  meant  in 
relation  to  the  commands  they  were  executing. 

The  concept  of  'loop'  (repetition  ot  a  set  of  com- 
mands) was  much  easier  to  grasp  than  that  of  a  condition- 
al exit  from  a  'loop'  ('out'  upon  failure) .  We  believe 
that  this  is  because  a  conditional  exit  is  influenced  by 
more  factors  such  as  the  previous  conditions  and  its 
physical  location  within  the  'loop*. 

One  of  our  more  interesting  observations  concerns  the 
ability  to  use  commands  in  the  'immediate  execution'  and 
program  writing  modes.  After  all  commands  had  been 
successfully  used  in  the  'immediate  execution'  mode  and 
the  concept  of  program  writing  understood,  we  thought 
that  the  knowledge  of  the  commands  would  be  transf errab le 
to  program  writing.  This  did  not  seem  to  be  the  case. 
When  programming  was  introduced  to  a  child  using  one  or 
two  commands,  the  child  could  use  only  these  commands  in 
programs.  Each  command  had  to  be  reintroduced  in  the 
program  writing  mode  until  about  five  commands  had  been 
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so  used.  At  that  point  the  children  were  able  to  use  the 
remaining  commands  in  writing  programs,  even  if  those 
commands  had  only  been  introduced  in  the  'immediate 
execution'  moie. 

When  the  children  had  difficulty  translating  commands 
from  the  'immediate  execution*  to  the  prog  ramming  mode, 
they  found  it  helpful  to  remember  hov  a  command  was  usel 
1  ;i  the  'immediate  execution'  'node.  Thus  it  seemed 
beneficial  that  they  could  use  the  'immediate  execution' 
mole  to  familiarize  themselves  with  the  commands  before 
they  began  to  program  as  well  as  return  to  this  mode  to 
remind  themselves  of  how  the  commands  worked  while  they 
were  writing  a    program. 

The  concept  of  the  system  being  in  different  modes  is 
ilso  abstract  and  was  difficult  foi.  tae  children  to 
master.  They  hid  trouble  realizing  which  mode  they  were 
in  and  how  that  would  affect  their  use  of  different 
language  commands.  Often  tney  didn't  remember  that 
stored  programs  hail  to  be  recalled  from  the  'immediate 
execution'  mode.  If  a  program  name  in  the  'program 
store'  is  touched  while  the  system  is  in  the  'write' 
mode,  the  program  name  will  appear  in  the  'current 
program'  as  a  subroutine. 
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Editing  programs  was  no  problem  after  the  children 
understood  the  different  modes.  They  also  had  little 
trouble  grasping  the  concept  of  subroutines,  although 
that  was  harder  than  using  primitive  language  commands. 

The  program  pointer  and  the  execution  sequence  of 
programs  were  not  difficult  concepts  for  the  children  to 
understand.  In  PAL  the  program  pointer  is  always  visible 
while  a  program  is  executing,  thus  the  execution  of  a 
program  is  also  an  immediately  visible  event. 
1.4.2  Analyzing  and  Debugging  Programs  Improved. 

The  children's  ability  to  analyze  programs  improved 
greatly  over  the  course  of  the  sessions;  they  overcame 
the  fear  of  making  mistakes.  Their  operational  knowledge 
of  PAL,  however,  increased  more  quickly  than  their 
ability  to  verbalize  this  knowledge. 
1.4.1  Children's  Original  Ideas  Increased. 

In  the  first  few  sessions  the  children  seldom  came  up 
with  ideas  for  their  programs.  They  enjoyed  programming 
and  were  glad  when  John  or  Hanna  suggested  a  program 
topic.  This  did  change  somewhat  in  later  sessions. 
Linda,  for  example,  hid  an  idea  for  having  a  program 
write  "Hello  There"  onto  the  'play  area'.  When  drawing 
pictures  in  the  'immediate  execution'  mode  she  came  up 
with  original  ideas  such  as  putting  a  car  into  a   garage. 
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rt  would  seem  tnat  oncre  children  become  T.>re  confident 
with  writing  projrims  they  may  come  up  with  lore  ideas  of 
their  own.  A  classroom  environment  would  also  tend  to 
tost or    competitive    ideas. 
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4  Concluding  Thoughts. 

4.  1  Recommendations  foe  Teaching  PAL. 

Wf>  believe  that  children  younger  than  those  used  in  out 
study  can  be  introduced  to  PAL.  Our  recommendations  are  to 
begin  introducing  PAL  in  a  classroom  setting  in  first  grade 
or  Kindergardeu  and  use  it  as  the  first  in  a  seguence  of 
mini -languages.  In  the  beginning  the  children  should  have 
very  short  sessions  in  which  they  use  the  'immediate 
execution*  mode  to  draw  pictures,  got  used  to  computer 
terminals,  learn  to  use  the  language  commands  and  expand 
their  imaginations  by  competing  with  their  peers  in  drawing 
pictures.  When  several  children  are  confident  with  the 
•immediate  execution'  mode,  they  can  be  instructed  in 
programming.  These  children  can  then  help  others  learn  new 
programming  concepts.  Finally,  PAL  could  serve  as  an  extra 
activity  for  children  who  have  finished  their  regular  class 
work. 

4.2  PAL  is  a  Good  Vehicle  for  Teaching  Programming. 

Programming  is  taught  conventionally  at  tne  University 
level  in  one  semester  for  an  average  of  3  hours  per  week. 
Young  children  seem  to  learn  the  concepts  of  programming 
more  quickly,  partially,  it  seems,  because  of  the  features 
of  the  PAL  system.   In  PAL  the  program  execution  and 
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program   pointer   are   visible-    Thus  1the  students  gain  a 
cleii  understanding  of  what  program  execution  au»ans. 

The  'immediate  execution'  mode  also  seems  to  be  very 
helpful  in  introducing  programming.  Pa  pert  uses  the  'imme- 
diate execution*  concept  to  get  children  familiar  with 
commands  (21)  ,  Tin  above-mentioned  ideas  could  tie  carried 
over  to  high  school  and  college  programming  courses. 
4.3  Future  Considerations. 

One  possible  expansion  of  PAL  is  the  use  of  audio  for 
the  error  and  other  messages.  Another  possibility  is  to 
add  commands  which  request  input  from  the  terminal,  the 
introduction  of  arithmetic  algorithms  and  a  random  number 
generator.  It  could  be  possible  for  children  to  take  home 
cartoon  books  vhicn  they  have  created  in  their  PAL 
sessions. 

I"n  analogy  to  Piaget's  studies  (particular  those  of  math 
concepts)  ,   on*'   might  investigate  at  what  age  children  can 
understand  various  programming  concepts. 
4.  4  Conclusions. 

In  PAL  we  believe  we  have  reached  our  initial  goals, 
namely  to  develop  a  simple  computer  language  for  children 
which  could  be  used  to  teach  them  how  to  program  as  well  as 
study  how  these  children  learn  to  program.  Our  preliminary 
tests  have  shown  that  interesting  observations  can  be  made 


113 


by  analyzing  these  programming  efforts.  We  feel  that 
similar  tests  can  contribute  to  our  knowledge  of  the 
process  by  which  programming  is  learned  *nd  help  us  improve 
thf»  teaching  of  programming  in  general. 
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APPENDIX    A 


DEVELOPMENT     AND     DESIGN     NOTES. 


1,       Design    f?oals. 

One  of  the  goals  in  designing  PAL  was  to  create  the 
simplest  possible  language  to  avoid  influencing  the  study  by 
the    structure    of       the      language.  if  e      strove      to      implement 

programming  concepts  in  the  easiest  possible  way,  with  a 
minimum  of  syntactical  constrictions.  Most  sequences  of 
commands  should  have  soma  visible  effect  which  can  be 
analyzed  and  debugged.  We  wanted  to  test  how  the  concepts 
were  learned,  not  how  easy  or  difficult  it  was  to  work  with 
idiosyncracies   of    a    language. 

Since  PAL  was  designed  for  use  by  children,  we  wanted  to 
eliminate  as  many  prerequisites  to  its  use  as  possible.  We 
wanted  children  who  could  not  yet  read  or  write  to  be  able 
to  use  PAL,  to  be  able  to  write  programs  which  would  be 
interesting    and    relevant    to   them.  At      the      same      time,       we 

wanted  to  make  maximum  use  of  the  special  features  of  the 
PLATO    system. 


Tmple.iientat ion    of    Version    1. 

The  first  design  decision  was  to  use  symbols  instead  of 
words  to  avoid  dependence  on  reading  skills.  We  also 
decided  to  use  the  PLATO  screen  to  simulate  a  computer.  The 
different  parts  of  the  system,  the  memory,  commands,  work- 
space, stored  programs,  etc.  would  be  visible  at  all  times. 
Commands  would  be  accessed  by  simply  touching  them  (taking 
advantage  of  the  PLATO  touch  panel)  and  represented  by 
pictures  symbolic  of  their  function  (possible  because  of 
PLATO's  special  character  design  teature).  Since  the  com- 
mands would  be  on  the  screen,  the  child  would  be  reminded  of 
what  is  available  to  him.  The  system  commands  were 
separated  from  the  language  commands  to  indicate  differences 
in  function  and  separated  from  each  other  to  avoid  missed 
touches.       The    'play    area1    was    placed    in    the    center    of    the 
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screen  as  the  center  of  activity  surrounded  by  a  "buffer"  to 
give  a  margin  for  inaccurate  touches.  The  'play  area* 
addresses  were  to  be  referenced  bv  coordinates  with  the 
x-coordinates  depicted  by  lower-case  letters  to  distinguish 
them  from  the  y- coord ina tes  represented  by  capital  letters. 

The   memory  implementation  was  decided  on  after  consider- 
ing a  "virtual"  type  of  memory  that  could  be   "rolled".    We 
decided   against   that   for  compactness  of  the  Language  (the 
amount  of  space  PAL  would  take  up  in  the  rest  of  the  system) 
and  ease  of  use. 

The  'loops'  in  PAL  were  chosen  for  their  simplicity: 
'loop'  brackets  surrounding  the  sequence  of  instructions  to 
be  repeated.  Number  skills  are  not  necessary  to  use  the 
'loops'.  The  "failing"  of  commands  was  chosen  as  the 
criteria  for  'exiting'  a  'loop'  since  "failure"  is  easy  to 
recognize  and  understand  in  the  context  of  PAL.  We  decided 
that  the  'exit'  command  would  have  to  be  present  in  the 
'loop'  for  the  program  pointer  to  'exit*  sine?  the  concept 
of  conditional  branching  is  important. 

We  wanted  to  implement  an  'immediate  execution'  mode  to 
permit  children  to  familiarize  themselves  with  commands  as 
well  as  with  the  idea  of  "telling  the  computer  «(hat  to  do". 
We  also  considered  a  "combination  mode"  which  ^oth  "immedi- 
ately executed"  a  command  as  it  was  touched  and  also  stored 
it  in  the  'current  pLogram*  (functioned  as  a  combination  of 
'write'  and  'immediate  execution'  modes).  It  was  decided 
that  this  "mode"  was  too  artificial,  since  it  had  no 
parallels  in  the  world  of  "real"  languages.  We  also  felt 
that  it  would  prevent  the  children  from  gaining  familiarity 
with  writing  a  sequence  of  commands  which  do  nothing  till 
they  are  'run'. 


1.   Changes  Resulting  in  Version  2. 

The  first  testi  with  children  (preliminary  tests  and  the 
ones  with  Timmy)  indicated  areas  where  PAL  should  be  changed 
to  make  the  system  easier  to  use  and  more  internally 
consistent.  One  thing  we  noticed  was  that  one  square  should 
always  be  'active'  in  the  'play  area'.  In  version  1  the 
'active  square'  could  be  located  in  the  'store'  or  the 
'program  store'.  A  position  in  the  'plav  area'  or  the 
'store'  could  be  male  the  current  'active  square'  by 
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touching  it.  We  noticed  that  the  only  command  that  could  act 
on  an  active  'store'  picture  was  'pick  up'-  Tn  version  2 
touching  a  'store'  picture  causes  it  to  he  automatically 
'picked  up*.  This  eliminated  the  major  syntactical  con- 
straint in  PAL,  one  with  which  the  children  had  difficulties 
because  they  often  got  the  'pick  up',  'drop'  sequence   wrong. 

Also  in  version  2  when  an  entry  in  the  'program  store'  is 
touched  while  the  system  is  in  the  'immediate  execution' 
mode,  it  is  automatically  displayed  in  the  'program  space* 
and  becomes  the  "current  program".  In  version  1  the  'active 
squarp'  indicator  ((lotted  box)  would  appear  around  the 
program  name  (the  one  touched).  To  display  the  program,  it 
had  to  be  'run'. 

Touching  'wrap'  in  version  1  caused  the  'current  program* 
to  be  erased  from  the  *  program  space*.  The  system  returned 
with  a  request  to  touch  -NEXT-  if  a  new  program  is  to  be 
started.  This  seemed  inconsistent  and  left  the  children 
confused  as  to  what  they  should  do  if  they  didn't  want  to 
start  another  program.  In  version  2  the  program  remains  in 
the  'program  space'  and  can  be  added  to  or  edited.  'Write* 
must  be  touched  if  a  new  program  is  to  be  started.  (Other 
system  commands  can  be  executed  in  bot h  versions. ) 

It  is  also  possible  to  edit  a  program  in  version  2.    If, 

instead  of   typing   a  name  for  a  new  program  after  touching 

'write',  a   stored   program   is   touched,   that   program   is 

recalled  and  can  be  edited. 

The  screen  was  also  slightly  rearranged.  In  version  1 
programs  were  stored  in  the  same  'store*  as  the  pictures. 
It  was  also  possible  to  store  composite  pictures  which  we 
felt  was  not  necessary  since  a  program  to  create  composite 
pictures  could  be  easily  written.  We  also  decided  to  put 
stored  programs  near  the  language  commands  to  remind  the 
children  that  they  are  both  used  in  the  same  way.  Prede- 
fined programs  were  added  to  introduce  an  additional 
concept. 

The  tests  with  children  indicated  that  it  was  important 
to  erase  the  'play  area*  before  re-executing  a  program.  In 
version  1  the  -LAB-  key  had  to  be  pressed,  which  the 
children  often  forgot  to  do.  Thus  we  put  a  'broom'  on  the 
screen  near  the  system  commands  to  ease  its  use  and  remind 
the  children  to  initialize  the  'play  area'  when  necessary. 


120 


Another  minor  change  was  to  change  the  name  'exit*  to  the 
easier  name  'out'.  We  also  decided  to  make  a  pointing  hand 
the  symbol  for  the  'immediate  execution'  (or  'Jo')  mode  and 
to  have  the  same  symbol  represent  the  program  pointer.  In 
version  2  the  positions  in  the  'play  area'  aro  represented 
by  their  coordinates  in  a  program,  while  in  version  1  they 
are  represented  by  a  hand  pointing  at  the  coordinates- 
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FORMAL  DESCRIPTION  OF  PAL. 

(program)  ::=  (program  name>  <statement  list) 

(statement  list)  ::=  (statement)  I  (statement)  (statement  list> 

<stateraent>  ::-    begin  loop  (statement  list>  end  loop  | 
<program>  |  (command) 

I  (command)  ::=  drop  J  pick  up  |  erase  j  out  |  join  |  take  away  } 
move  right  j  move  left  |  move  up  j  move  down  | 
move  active  right  |  move  active  left  |  move  active  up  | 
move  active  down  J  (content)  |  <set  play  area> 

<set  play  area>  ::=  <lower  case  letter>  (capital  letter> 

<content>  ::=  <picture>  |  (character)  l  <letter> 

(program  name>  ::-  (letter)  |  (letter)  (letter)  |  ...   | 
(letter)  (letter)  (letter)  (letter) 

(character)  ::=  (lower  case  letter)  |  (capital  letter)  | 
(digit) 

(picture)  :  :=  house  |  tree  |  car  |  sun  \    witch  |  ,.. 

(digit)  ::=  0  |  1  ]  2  |  J  j  ...   |  9 

(lower  case  letter)  ::=a|b|c]dj...   J  z 

(capital  letter)  ::=A)3|C|D|...   |Z 
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APPENDIX  C 


A  BRIEF  DESCRIPTION  OF  THE  SESSIONS  WITH  CHILDREN. 


T  I  M  M  Y 


Session    1  :      2/14/75,     1    hoar    7    minutes. 

Timmy  learned  to  use  all  the  language  commands  in  the 
'immediate  execution'  mode  with  the  exception  of  'move 
active'    and    drew    complex    pictures    in    the    'play    area'. 


2§s.sion_2:       2/21/75,    1    hour. 

Timmy  used  the  'immediate  execution'  mode  for  the  first 
10  minutes  after  which  John  introduced  him  to  writing 
programs.  With  much  help  Timmy  wrote  "tim"  rfhich  put  a 
girl    into    the    'play    area'    and    moved    her    right    and    up. 


S§_ ssiQU-J  :       2/26/75,    40   minutes. 

John  reintroduced  the  concept  of  programming  to  Timmy 
who  was  distracted  by  the  presence  of  his  parents.  Tim 
wrote  a  program  consisting  of  'moves',  still  reguiring 
much    prompting.. 


Session_4:       2/23/75,    55    minutes. 

Tim  attempted  to  write  a  program  to  put  down  a  balloon 
with  no  help:  'pick  up',  aA,  'drop',  balloons,  several 
•moves'.  John  helped  Timmy  write  a  program  to  put  a 
boy  into  tne  'play  area'  and  Tim  added  'move'  commands 
to    the    program. 


^2^ 


5ej3sion_5:       3/13/75,    40    minutes. 

Tiramy  wanted  to  write  a  program  and  started  one  on  his 
own  but  didn't  know  how  to  continue  after  naming  it. 
After  a  short  explanation  by  John,  Tin my  wrote  the 
program  'city'  consisting  of  a  'set  play  area'  followed 
by  'move'  commands.  Tim  also  used  'city'  to  move  other 
pictures    such    as    a    girl    with    umbrella. 


Session  6 


3/19/75,  30  minutes. 


John  introducel  'loops'  and  in  his  first  attempt  to  use 
them  in  a  program,  Tim  reversed  the  'begin'  and  'end 
loops'-  Tim  fixed  the  program  which  consisted  of  a 
'set  play  area'  and  'moves'  inside  a  'loop'. 


Session_7x_3:   3/20  an  1  3/21/75,  30  minutes  each. 

Timmy  practiced  using  PAL  at  his  school.  Hanna  only 
observed  and  answered  questions;  Tim  worked  by  himself 
to  gain  confidence  with  PAL.  Timmy  wrote  the  programs 
'copy'  and  'zoom'  which  put  a  car  in  th?  'play  area' 
and  moved  it.  Both  programs  used  'loops'  which  con- 
tained 'exits '. 


Session_9;   4/25/75,  50  minutes. 

Timmy  wrote  on  nis  own  the  program  "help"  which  placed 
a  girl  onto  the  'play  area'  and  moved  her.  In  his 
initial  attempt  he  put  a  'set  active  square'  before  the 
'move'  commands,  but  corrected  his  mistake  by  analyzing 
the  program.  Hanna  then  wrote  a  program  to  draw  a  line 
of  a  checkerboard  which  ended  with  two  solid  squares. 
Tim  corrected  the  problem  with  no  help  by  adding  an 
'erase'  command  to  the  program. 


§£§sion_1_0:   7/14/75,  ^0  minutes. 

Hanna  reintroduced  the  concept  of  program  writing 


124 


because  of  the  long  interval  between  sessions  9  and  10. 
With  very  little  help  Timmy  wrote  the  program  •ivy' 
which  placed  a  tree  into  the  'play  area1  and  moved  it 
up  and  down  (using  an  infinite  'loop1). 


Session,! 1  :   7/16/75,  40  minutes. 

Timmy  constructed  an  "X"  in  the  *  immediate  execution* 
mode  using  the  slanted  line.  He  then  wrote  two 
programs  to  compose  an  "X",  the  first  with  help,  the 
second  by  himself. 


Session  12:   7/26/7  5,  1  hour. 

Timmy  executed  the  program  'ivy'  which  he  wrote  in 
session  10.  He  then  explained  what  'loops*  do.  John 
suggested  writing  a  program  which  would  cause  two  cars 
to  crash  into  each  other.  With  confidence  Timmy  wrote 
a  program  which  put  two  cars  down,  and  caused  one  to 
move  into  the  other.  A  little  debugging  was  required 
to  have  the  cars  dissolve  into  smoke! 


§ession_Jl3:   7/27/75,  1  hour  40  minutes. 

Timmy  wanted  a  program  to  put  a  row  of  solids  onto  the 
•play  area'.  He  used  the  'pick  up',  'drop*  sequence 
and  thus  had  to  write  two  programs,  the  second  calling 
the  first  (he  had  forgotten  about  'loops1). 


Session 14:   8/1/75,  35  minutes. 

Timmy  wanted  to  make  a  witch  go  back  and  forth  (his  own 
idea).  After  a  little  trial  and  error  he  rediscovered 
the  'loop'  and  wrote  *rfty'  consisting  of  'move  left' 
and  'move  right'  inside  a  *loop*.  He  then  used  the 
program  to  move  several  other  picture  elements. 
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LINDA 


Session^:       1/19/77,     1    hour. 

After  35  minutes  Linda  was  comfortable  with  all  com- 
mands (including  'move  active')  in  the  'immediate 
execution*  mode.  Linda  drew  a  complex  composite  pic- 
ture consisting  ot  a  large  house  composed  of  line 
segments    and    a    car    in   a    garage. 


Session  _2:       1/21/77,     1    hour,     15    minutes. 

The  introduction  to  programming  began  15  minutes  into 
the  session.  Linda's  first  program  with  which  she 
needed  no  help  consisted  of  10  'store'  pictures  fol- 
lowed by:  'drop',  dE ,  house,  'drop'  (40  minutes  into 
the  session).  Five  minutes  later  she  wrote  a  program 
to    place    five    pictures   onto    the     'play   area'. 


Session    3:       1/24/77,     1    hour,     20    minutes. 

Eight  minutes  into  the  session  Hanna  asked  Linda  to 
write  a  program  which  puts  a  car  into  a  garage.  She 
was  unsure  of  herself  and  went  back  into  the  'immediate 
execution'  mole  two  times  to  remind  herself  of  which 
commands    to      use.  20      minutes      later      she      succeeded. 

Forty  minuter  after  the  start  of  the  session  Linda 
wrote  a  program  to  'move'  a  picture.  It  took  her  15 
minutes    to    write    the    program    and    debug    it. 


Se ssion_4 :       2/7/77,     1    hour,    20    minutes. 

Hanna  suggested  a  program  which  puts  a  boy  on  a  bike 
into  the  lowei.  left  corner  of  the  '  play  area'  and  moves 
him  across  to  the  lower  right  corner.  She  succeeded 
within  20  minutes  with  little  help.  Tn  15  more  minutes 
she  wrote  a  program  which  has  a  car  run  into  another 
one  and  go  up  in  smoke.  For  the  last  15  minutes  she 
composed    a    sentence    in    the    'play   area'- 
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Session  5:   2/11/77,  1  hour,  30  minutes. 

Linda  drew  a  picture  of  a  toystore  in  the  •immediate 
execution'  mode.  15  minutes  later  she  wrote  a  program 
to  have  a  witch  fly  over  the  toystore.  After  Hanna 
introduced  'loops',  Linda  wrote  the  program  which  has  a 
boy  on  a  bicyle  ride  across  the  'play  area*  using  a 
loop. 


Session  f:   2/14/77,  1  hour,  10  minutes. 

Hanna  suggested  drawing  a  row  of  trees  and  helped  Linda 
with  the  use  of  'move  active'.  Linda  wrote  (with 
several  hints)  'tree':  aG,  tree,  'drop',  bG,  'begin 
loop',  'drop',  'move  active  right',  'out',  'end  loop'. 
Hanna  showed  her  how  to  replace  the  loop  section  of  the 
program  with  a  predefined  procedure  called  'line1. 


Se§sion_7:   2/18/77,  1  hour,  35  minutes. 

In  this  session  Hanna  asked  Linda  for  an  idea  for  a 
program.  Linda  wrote  a  program  which  put  the  words 
"Hello  There"  onto  the  'play  area'.  She  had  to  use  two 
programs,  the  first  calling  the  second.  Hanna  then 
suggested  writiny  a  program  which  draws  a  checkerboard. 
While  her  first  attempt  did  produce  a  program  contain- 
ing a  'loop',  she  needed  some  help  to  complete  the 
project. 


Sessi on_8 :   2/22/77,  1  hour 


Since  this  was  the  last  session,  Linda  demonstrated  PAL 
and  the  programs  she  had  written  for  her  parents  and 
sisters.  Hanna  drew  a  maze  in  the  'play  area1  and 
asked  Linda  to  write  a  program  which  would  move  a  girl 
from  the  left  side  to  the  right  side  of  the  maze 
without  counting  the  number  of  arrows  (to  make  the 
program  general).  Linda  wrote  a  program  using  'nested 
loops'  with  very  few  hints. 
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PATRICK 


Session_J:       4/23/74,    1    hour. 

Patrick  learned  to  use  the  language  commands  in  the 
•immediate  execution'  mode  in  the  first  t€?n  minutes- 
He  enjoyed  using  the  'join'  and  'take  away'  commands 
most.  During  the  last  halt  hour  Pat  was  introduced  to 
programming  and,  with  some  guidance,  wrote  a  program 
which    moved    a    car    across    the    'play    area'. 


§£ssion_2:       5/2/74,    45    minutes. 

Pat  began  this  session  by  driwing  pictures  in  the 
•immediate  execution'  mode.  After  15  minutes  he  wrote 
a  program  which  put  a  sun  onto  the  center  of  the  screen 
and  a  man  walkinj  at  the  bottom.  One  half  hour  into 
the  session  Pat  was  introduced  to  subroutine  calling. 
With  very  little  help  he  then  wrote  a  program  which  put 
a  boy  holding  an  umbrella  onto  the  'play  irea'.  This 
"subroutine"  was  then  called  by  a  progra.ii  which  moved 
the    boy. 


J    0    D    I 


Sf25ion_J:       7/23/74,     30    minutes. 

Jodi  learned  about  the  'pick  up',  'drop'  sequence  and 
used  it  to  draw  a  picture.  The  session  was  interrupted 
bv    several    "crashes"    of    the    PLATO   system. 


Session 


9  - 


7/24/74,  55  minutes. 


Jodi  familiarized  herself  with  the  remaining  commands 
in  the  'immediate  execution'  mode*.  She  especially 
enioyed  using  'join*  and  'take  away'.   After  25  minutes 
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she      was      introduced      to      programming    and    attempted    her 
first    program    (with    help    from    Hanna)     15    minutes      later. 


5e§sion_3:       7/25/74,    50    minutes. 

Jodi  wrote  a  program  which  used  a  'Loop'  to  draw  a  row 
of  houses.  After  that  she  wrote  a  program  which  placed 
a    girl   on   a    bicycle   and    moved    them   across    the    screen. 


MIKE 


Session_J:   8/15/74,  40  minutes. 

Mike  learned  to  use  all  commands  in  the  *iamediate 
execution*  mode.  He  used  them  to  create  a  composite 
picture  in  the  •play  area1. 


Session  2:   8/16/74,  45  minutes. 

For  the  first  10  minutes  Mike  drew  pictures  in  the 
'immediate  execution*  mode.  After  that  he  was  intro- 
duced to  programming  and  wrote  a  program  which  put  a 
picture  on  the  'play  area*. 


Session  3:   8/20/74,  45  minutes. 

In  this  session  Mike  wrote  a  program  which  put  a  car 
onto  one  side  of  the  *play  area*  and  then  moved  it 
across  to  the  other  side.  He  noticed  quickly  that  he 
had  an  infinite  loop  in  his  first  attempt  and  corrected 
it  by  himself.  Mike  was  very  pleased  when  he  succeeded 
in  writing  a  program  which  placed  a  row  of  suns  across 
the  'play  area'  since  it  was  his  own  idea  and  he  did 
not  receive  any  help  with  the  programming. 
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SAMPLE  PAL  PROGRAMS. 


1.   Hello  There  (by  Linda) 
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1.       Drawing    diid    Escaping    from    a    'Maze'. 
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4.   Flashing  "Negative"  Sun. 
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VITA 

Hanna  Kammerahl  Kruczek  was  bocn  in  Bremerhaven,  West 
Germany,  on  February  19,  1948.  She  immigrated  to  Chicago  in 
1957  where  she  graduated  from  Nicholas  Senn  High  School  in 
February  of  1965  after  winning  the  Westinghouse  Science  Talent 
Search-  She  also  received  her  United  States  citizenship  in 
that  year.  Mrs-  Kruczek  began  to  study  mathematics  at  the 
University  of  Illinois,  Chicago  Circle  where  she  was  elected  a 
member  of  the  honor  soroity  Alpha  Lambda  Delta- 
After  completing  two  years  at  Chicago  Circle,  she  studied 
mathematics  for  two  more  years  at  the  Universitat  Hamburg  in 
West  Germany.  From  September  1969  to  January  1970  she  attended 
a  course  for  the  training  of  teachers  of  Transcendental 
Meditation  in  Rishikesh,  India.  She  also  worked  at  subsequent 
sessions  of  the  same  course  by  simultaneously  translating  the 
lectures  from  English  into  German.  Upon  returning  to  the 
United  States  in  May  of  1970  she  taught  Transcendental  Medita- 
tion full  time  until  that  August.  She  has  continued  to  teach 
part  time  since  then. 

Mrs.  Kruczek  entered  the  graduate  college  of  the  University 
of  Illinois  at  Urbana  in  1970,  receiving  her  AM  in  Mathematics 
in  February  of  1972.   She  then  began  to  pursue  her  doctorate  in 
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computer  science.  During  her  graduate  studies  at  Illinois,  she 
was  elected  to  associate  membership  in  Sigma  Xi,  a  research 
society.  She  was  also  a  member  of  the  Association  of  Computing 
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